G05 - Plan de Pruebas de SRA-ejm

FACULTAD DE INGENIERÍA
ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS
SISTEMA DE REGISTRO DE ASISTENCIA - ANÁLISIS DE

REQUERIMIENTOS
Integrantes:
Alarcon Castillo, Carlos Franco
Rojas Espinoza, Juan Carlos
Sánchez López, Fabián Leonel
Tasayco Tuanama, Luis Fernando
Vasquez Medina, Ana Kelly
Asesor:
Acosta Ticse, Deisy Lizbeth
Lima - Perú
2021
Plan de Pruebas del Sistema de Registro de Asistencia

Página 1
Contenido
INTRODUCCIÓN 6
PARTE I: EMPRESA 6
PROPÓSITO 6
DESCRIPCIÓN DE LA EMPRESA 6
GIRO DEL NEGOCIO 6
MISIÓN 8
VISIÓN 8
OBJETIVOS EMPRESARIALES 8
PROCESOS PRINCIPALES DE LA EMPRESA 8
PLANEAMIENTO ESTRATÉGICO DE TECNOLOGÍAS DE INFORMACIÓN: 10
PARTE II: PLAN DE GESTIÓN DE PROYECTO DE PRUEBAS DEL SRA. 13
INFORMACIÓN DEL PROYECTO 13
APROBACIONES 13
RESUMEN EJECUTIVO 14
1 ALCANCE 14
Personal involucrado 15
Definiciones, acrónimos y abreviaturas 16
Resumen 17
1.1 DESCRIPCIÓN GENERAL 17
1.1.1 Perspectiva del producto 17
1.1.2 Funcionalidad del producto 18
1.1.3 Modelamiento de Casos de uso de SRA: 18
1.1.4 Características de los usuarios 21
1.1.5 Restricciones 22
1.1.6 Suposiciones y dependencias 22
1.1.7 Evolución previsible del sistema 22
1.2 REQUISITOS ESPECÍFICOS 22
1.2.1 REQUISITOS COMUNES DE LAS INTERFACES 22

Página 2
1.2.1.1 Interfaces de usuario 22
1.2.1.2 Interfaces de hardware 22
1.2.1.3 Interfaces de software 23
1.2.1.4 Interfaces de comunicación 23
1.2.2 REQUISITOS FUNCIONALES 23
1.2.2.1 Ingreso a la aplicación 23
1.2.2.2 Administración de asistencia 24
1.2.2.3 Administración de reporte 24
1.2.3 REQUISITOS NO FUNCIONALES 25
1.2.3.1 Requisitos de rendimiento 25
1.2.3.2 Seguridad 25
1.2.3.3 Fiabilidad 25
1.2.3.4 Disponibilidad 25
1.2.3.5 Mantenibilidad 25
1.2.3.6 Portabilidad 26
1.2.4 Otros requisitos 26
2 PLAN DE GESTIÓN DE CALIDAD 26
2.1 ALCANCE DE LAS PRUEBAS 26
2.1.1 Elementos de pruebas 26
2.1.2 Nuevas funcionalidades a probar. 26
2.1.3 Pruebas de regresión 28
2.1.4 Funcionalidades a no probar 29
2.2 PROCEDIMIENTOS PARA LAS PRUEBAS 29
2.2.1 Criterios de aceptación o rechazo 30
2.2.2 Criterios de suspensión 31
2.2.3 Criterios de reanudación 33
2.2.4 Roles del personal: 33
2.2.5 Matriz de responsabilidades: 34
2.2.6 Cronograma: 35

Página 3
2.2.7 Premisas: 36
2.2.8 Dependencias y Riesgos: 37
2.3 RECURSOS Y HERRAMIENTAS DE PRUEBAS 37
2.3.1 Requerimientos de Entornos – Hardware 37
2.3.2 Requerimientos de Entornos – Software 37
2.3.3 Herramientas de Pruebas Requeridas 38
2.3.3.1 SONARQUBE: 38
2.3.3.2 PHPUnit: 39
PARTE III: DESARROLLO CON HERRAMIENTA DE MEDICIÓN 40
1 PLAN DE PRUEBAS DE SOFTWARE: 40
1.1 Enfoque de pruebas 40
2 HERRAMIENTA DE CALIDAD DEL PRODUCTO (SonarQube) 41
2.1 Instalación y descripción de uso del SonarQube: 41
3.2 Leyenda de la herramienta: 46
2.3 Gravedad del problema: 47
3 HERRAMIENTA DE PRUEBAS UNITARIAS (PHPUnit) 49
3.1 Instalación y descripción de uso del PHPUnit: 49
3.2 Leyenda de herramienta: 55
3.3 Gravedad del Problema: 55
4 PRUEBAS UNITARIAS A 2 PROCESOS: Evaluación 56
4.1 PHPUnit ejemplo 56
4.2 SonarQube ejemplo sra: 61
5 Benchmarking: 64
3 Entregables de pruebas 65
CONCLUSIONES Y RECOMENDACIONES 65
BIBLIOGRAFÍA: 65
1.3 Referencia 65
ANEXOS SUGERIDOS: 66
1 PROJECT CHARTER 66

Página 4
2 ESTRUCTURA DE DESGLOSE DE TRABAJO: EDT 71
3 JMeter 72
Historial de versiones
Fecha Versión Autores Organización Descripción
16/04/21 SRA001 Grupo 05 Sistema de Registro Especificación de Requisitos
de Asistencia. del Software ERS
09/05/21 SRA002 Grupo 05 Sistema de Registro Plan de pruebas de SRA con
de Asistencia. SonarQube - SonarLint
16/05/21 SRA003 Grupo 05 Sistema de Registro Plan de pruebas de SRA con
de Asistencia. PHPUnit - PhpLint

Página 5
INTRODUCCIÓN
El área de recursos humanos requiere el servicio de gestión de ingresos y salidas
por parte del personal corporativo, para el correcto seguimiento de accesos en el
horario laboral de la empresa, a fin de generar una constancia de concurrencia de
los colaboradores, ya que es la forma más eficaz de conocer el cumplimiento del
horario de los trabajadores en el horario laboral de los mismos mediante un registro.
La necesidad concreta es la de proporcionar una herramienta que permita a los

administrativos visualizar un registro tanto de las asistencias como de los incidentes
por parte de los colaboradores, ya sea en interfaces en el lenguaje PHP o en una
página web interna y exclusiva a la empresa.
PARTE I: EMPRESA
PROPÓSITO
La presente documentación tiene como finalidad delimitar las especificaciones
funcionales y no funcionales del sistema web para el control de asistencias el cual
permitirá gestionar la información detallada de cada uno de los colaboradores
mediante el registro de ingresos, de los mismos. Permitiendo a los supervisores y
RRHH utilizar dicha data para la correcta toma de decisiones en cuanto a las
remuneraciones.
DESCRIPCIÓN DE LA EMPRESA
Dynamicall es un Contact Center multicanal ubicado en Perú, cuenta con más de 10

años de experiencia. Se especializa en outsourcing de ventas, retenciones,
servicios de back office y de atención al cliente, con una estrategia completa que les
permita amoldarse a los procesos de sus clientes.
GIRO DEL NEGOCIO
Dynamicall cuenta con un rubro de negocio orientado B2B, buscan ser socios
estratégicos para ayudar a reducir costos y mejorar resultados, a continuación, un
detalle de los servicios.

Página 6
● Atención al Cliente
INBOUND ● Reclamos
● información y Consultas
● Gestión Promocional
● Ventas / Preventas / Citas
OUTBOUND ● Generación y Actualización de Base de Datos.
● Encuestas de Satisfacción al Cliente.
● Fidelización de Clientes.
● Selección y Capacitación
CONSULTORÍA ● Gestión de la Calidad
CALL CENTER ● Control de Gestión
● Tecnología de la información.
● Gestión de reclamos bajo la normativa de Osiptel o

SERVICIOS Indecopi.
BACK OFFICE ● Análisis de aprobación de línea postpago a través de un
scoring.
● Soporte Operacional
BPO ● Atención de Reclamos.
● Courier
● Delivery Técnico
● Speech Analytics
INTELIGENCIA ● ChatBot
ARTIFICIAL ● IVR inteligentes
● Desarrollo de aplicaciones web y cliente servidor.

APLICACIONES ● Desarrollo de aplicaciones móviles.
A MEDIDA ● Integración de sistemas.
● Manejo de integración CTI con diversas plataformas.
● Whatsapp (API oficial)
SERVICIOS ● Facebook Messenger y Muro
OMNICANAL ● Twitter
● Instagram
● Correo electrónico
● Youtube

Página 7
MISIÓN
Implementar procesos integrales y de calidad permanentemente adaptados a la

realidad cambiante, con un equipo de personas de enfoque flexible y orientado a
lograr satisfacción, eficiencia sostenible y mejora continua.
VISIÓN
Ser en el 2021 la mejor empresa para contratar y trabajar en el Perú, capaz de

ofrecer una gran experiencia a nuestros clientes.
OBJETIVOS EMPRESARIALES
● Reducir costos y mejorar resultados de sus clientes.

● Estar alineados siempre a la tecnología y personal altamente calificado para
lograr los mejores resultados.
● Mejorar los resultados financieros de forma rápida y estructurada a sus
socios a través de estrategias sincronizadas.
PROCESOS PRINCIPALES DE LA EMPRESA
Dynamicall es una empresa creada para brindar excelencia en la gestión de ventas

(outbound) y servicio de atención al cliente (inbound).
Especialmente cuidadosos en cuatro aspectos que consideramos fundamentales
para brindar un servicio de calidad:
● equipo humano.
● plataforma tecnológica.
● infraestructura física.
● procesos operativos estandarizados.
Tienen áreas de direccionamiento para las concesionarias como son:
● CONSULTORÍA CALL CENTER: Tiene la selección y capacitación a sus

trabajadores maneja una buena Gestión de la Calidad, Control de Gestión y
Tecnología de la información.
● INBOUND: Que traducido literalmente como mercadotecnia interna y es más

conocido como marketing de atracción tiene como finalidad la Atención al
Cliente, Reclamos, información y Consultas y Gestión Promocional.
● OUTBOUND: Es el conjunto de acciones de marketing que tienen el objetivo

de captar consumidores mediante métodos directos y unidireccionales que
tiene como finalidad de ventas / Preventas / Citas, Generación y

Página 8
Actualización de Base de Datos, Encuestas de Satisfacción al Cliente y

Fidelización de Clientes.
● SERVICIOS BACK OFFICE: Engloba todas aquellas actividades

relacionadas con la gestión interna de una empresa como:
➔ Gestión de reclamos bajo la normativa de Osiptel o Indecopi.

➔ Análisis de aprobación de línea postpago a través de un scoring
● BPO: Business Process Outsourcing (BPO), el sector de tercerización de

procesos de negocio, se entiende como la delegación de uno o más
procesos de negocio y sus contenidos son Soporte Operacional, Atención de
Reclamos, Courier y Delivery Técnico
● INTELIGENCIA ARTIFICIAL: Es la combinación de algoritmos planteados

con el propósito de crear máquinas que presenten las mismas capacidades
que el ser humano las funciones son, Speech Analytics, ChatBot y IVR
inteligentes.
● APLICACIONES A MEDIDA: Conocido como software personalizado

teniendo como Desarrollo de aplicaciones web y cliente servidor, Desarrollo
de aplicaciones móviles, Integración de sistemas y Manejo de integración
CTI con diversas plataformas.
● SERVICIOS OMNICANAL: Una estrategia de marketing que busca ofrecer

una experiencia única e interconectada a los clientes a través del diálogo y
alineación de canales online y offline como son Whatsapp (API oficial),
Facebook Messenger y Muro, Twitter, Instagram, Correo electrónico y
Youtube.
● CLIENTES: Somos conscientes que el cliente representa nuestra razón de

ser como negocio, y debemos estudiar continuamente sus deseos y
requerimientos para lograr mantener en alto nivel de satisfacción de los
mismos en el proceso de atención al cliente es:
➔ LA AGILIDAD: Constituye el principal aspecto valorado y hace alusión a

la rapidez (el tiempo), contribuyendo a mejorar el tiempo de respuesta a
nuestros clientes.
➔ TRÁMITE: Se refiere a los menores requisitos y exigencias para la

documentación y el perfeccionamiento de atención.

Página 9
Organigrama de Dynamicall
PLANEAMIENTO ESTRATÉGICO DE TECNOLOGÍAS DE

INFORMACIÓN:
Sistema de Registro de Asistencia (SRA), pero se le ha realizado un Análisis del

micro entorno de la empresa bajo el enfoque de las Fuerzas de Porter, un Análisis
Industrial y un Análisis de FODA.
ANALISIS DE FODA:
-Fortalezas
● Evitar que los clientes tengan que hacer inversiones en infraestructuras y

personal para instalar un Call Center.
● Los clientes pueden acceder a tecnologías que individualmente es muy
costosa de conseguir.
● Transforma gastos fijos en gastos variables
● Disponibilidad flexible y dinámica que permite enfrentar con éxito demandas
variables de atención
● Los clientes evitan problemas laborales con nuevas contrataciones y
administración de personal
● Puede ser atendido de manera centralizada con cobertura nacional.

Página 10
-Oportunidades
● Integrar a la empresa nuevos sistemas.

● Extender y potenciar áreas del negocio de manera integrada
● Acceso a tecnologías, difícil de obtener de manera in House.
● Concentración en Nicho de Mercado
-Debilidades
● El cliente tiene acceso a diferentes tipos de proveedores con lo cual es fácil

de cambiar a este o particionarlo.
● La rotación del personal es alta, con lo cual hay que estar constantemente
capacitando.
● La tecnología no es un diferenciador, sino el servicio y gestión de estos.
-Amenazas
● Automatización de servicios cada vez más intensa.

● Teletrabajo como sustituto (Homework)
COMPETENCIAS:
● Un mercado competitivo, en el usuario a reclamar servicio de valor y exigir la

forma en la que quieren relacionarse con la empresa.
● Esto obliga a que la call centers tradicionales se conviertan en contact
centers, donde se integran diversos canales de interacción con la empresa
como teléfonos, e-mail, sms entre otros con la misma sencillez y eficacia que
proporciona una solución de centro de atención telefónica y ofreciendo a los
clientes un único punto de contacto para resolver sus necesidades,
GESTIÓN DE TALENTO:
El mejor equipo gerencial del mercado y programas motivacionales permanentes

para todo el personal.
● Estrategias de detección de habilidades y capacidades para definir el

perfil del personal.
● Capacitación permanente y refuerzos de conocimientos para mejorar la
productividad.
● Equipo gerencial experimentado.
● Estrategias de detección de habilidades y capacidades para definir el
perfil del personal.
● Programas motivacionales permanentes, para controlar la rotación de
personal.

Página 11
● Certificaciones internas.
PROCESOS SISTEMATIZADOS DE CONTROL DE GESTIÓN:
Sistema de gestión de indicadores, optimización de recursos involucrados y

cumplimiento de metas.
● Adaptabilidad a los procesos, horarios y enfoque de nuestros clientes.

● Políticas de seguridad.
● Control de información.
● Estructura de procesos y gestión que permiten un bajo overhead.
● Sistema de gestión de indicadores.
● Optimización de recursos
● Cumplimiento de metas.
TECNOLOGÍA:
Soporte tecnológico en cada fase del proceso de negocio para mayor efectividad.
● Marcador automático progresivo y predictivo para optimizar la producción,

que permite cross selling, scripting, CRM, agenda automática y grabación de
llamadas, entre otros.
● Sistema de reportes automáticos y de detección de fallas en cada fase.
● Servidores con discos espejo que respaldan el 100% de los servicios y la
posibilidad de contar con gestiones de 24x7x365.
● Soporte tecnológico en cada fase del proceso de negocio para mayor
efectividad.
ESTRATEGIAS IMPORTANTES:
Permitir la adaptación de los procesos de cada cliente y aplicar las mejores

prácticas experimentadas en la industria. Combinar eficiencia, flexibilidad y
perfeccionamiento logrando que la inversión del cliente se vea reflejada en mayor
productividad.
CONCLUSIONES:
El área de call center técnico se encarga de atender las llamadas entrantes que
realizan los usuarios de servicio de banda ancha, quienes se comunican al área
a través del canal 123. El staff de asesores debe de resolver toda clase de
solicitud de soporte técnico del SBA (Small Business Administration) de los
usuarios. Sin embargo, el total de llamadas entrantes no son atendidas
generando llamadas abandonadas y llamadas atendidas fuera del tiempo
establecido por el cliente. En este sentido, el área presenta problemas de
operatividad que deben ser analizadas y resueltas.
Página 12
PARTE II: PLAN DE GESTIÓN DE PROYECTO DE

PRUEBAS DEL SRA.
INFORMACIÓN DEL PROYECTO
Empresa / Organización Sistema de registro de asistencia (SRA)
Proyecto Desarrollo, implementación e testing SRA
Fecha de preparación 16/04/21
Cliente Gerente general:
ENRIQUE BELTRÁN CORNEJO - Representante de
DYNAMICALL
Patrocinadores principales Alarcón Castillo, Carlos Franco
Sánchez López, Fabian Leonel
Tasayco tuanama, Luis fernando
Vásquez Medina, Ana Kelly
Gerente / Líder de proyecto Vásquez Medina, Ana Kelly
Gerente / Líder de desarrollo Tasayco tuanama, Luis fernando.
de sistema
APROBACIONES
Nombre y Apellido Cargo Departamento u Fecha Firma
organización
Rojas Espinoza, Juan Desarrollador 09/05/21
Carlos Frontend Dirección y gerencia
Vasquez Medina, Ana Analista de sistemas 09/05/21
Kelly Diseño del sistema
Sanchez Lopez, Fabian Administrador de 09/05/21
Leonel Base de Datos Administrador del sistema
Tasayco tuanama Luis Desarrollador Backend Desarrollo del sistema 09/05/21
fernando
Alarcón Castillo, Carlos Backend Testing Tester 09/05/21
Franco
RESUMEN EJECUTIVO
Este documento tiene como propósito evaluar los errores y defectos que pueden
existir en un sistema, con el fin de corregirlos. Validar que los datos funcionen
correctamente y determinen el ingreso de información adecuada.
Verificar que los validadores de datos funcionen y limiten el ingreso de información,

para que no se puedan ingresar datos que no están permitidos (sólo números en
campos numéricos, por ejemplo).

Página 13
El sistema a desarrollar será a nivel de aplicación web, y tendrá que pasar

evaluaciones de aceptación de los colaboradores y supervisores. Con el requisito
de optimizar los procesos de recursos humanos para validar las asistencias de
nuestros colaboradores.
1 ALCANCE
Implementación y desarrollo de una aplicación web denominada Sistema de
Registro de Asistencias (SRA).
El sistema a desarrollar será a nivel de aplicación web, y tendrá que pasar

evaluaciones de aceptación de los colaboradores y supervisores.
En su fase de producción, el sistema dará apoyo a los siguientes procesos:

● Registro y control de asistencias: Inmediato, a largo plazo y a muy largo
plazo.
● Exportación de los reportes de asistencias.
Igualmente, facilitará a los administrativos contar con herramientas que les permita
la visualización de tablas informativas con las relaciones por índices de puntualidad,
tardanzas y faltas en el rango del horario laboral establecido, el cual se obtendrá en
base a los datos proporcionados por el algoritmo del sistema desarrollado en PHP
programados en el sistema web.
Además, trabajará con la consulta de datos ingresados por los diferentes

colaboradores. Asimismo, contará con una conexión a la intranet, navegadores web
de la empresa, ya que el sistema se encontrará alojado en el servidor local de la
misma.
Asimismo, por cada ingreso de datos por parte de los colaboradores al sistema, los
encargados del área de recursos humanos podrán exportar un reporte de las
asistencias.
Personal involucrado
Nombre Alarcón Castillo, Carlos Franco
Rol Backend Testing
Categoría profesional Ingeniero de Sistemas
Responsabilidades Diseñar la interfaz gráfica del sistema según los
requerimientos del cliente.
Información de contacto [email protected]
Nombre Rojas Espinoza, Juan Carlos

Página 14
Rol Desarrollador Frontend

Responsabilidades Adaptar y diseñar el sistema de información para trabajar de
forma más rápida y eficiente.
Nombre Sánchez López, Fabian Leonel

Rol Administrador de base de datos
Responsabilidades Configurar, administrar y mantener los sistemas de base de
datos.
Nombre Tasayco tuanama Luis fernando

Rol Desarrollador Backend
Responsabilidades Programar la funcionalidad del sistema en base a los
requerimientos obtenidos.
Nombre Vásquez Medina, Ana Kelly

Rol Analista de sistemas
Responsabilidades Proporcionar informes al equipo del proyecto sobre cualquier
problema o mejora que el sistema pueda requerir.
Definiciones, acrónimos y abreviaturas

Del Negocio:
● Registro: Almacenar datos o dejar constancia de ello en un fichero.

● Incidencia: Evento que suscita un colaborador en un momento
determinado como, tardanzas, faltas, licencias, factores externos, etc.
● Control: Gestión de la información ingresada al sistema para su
posterior utilización en el análisis de desempeño laboral.
● Reporte: Informe sobre los acontecimientos recientes de los
usuarios(asistencias) a través de un pdf.
Del Sistema:
● Interfaz: Conexión funcional entre dos sistemas, programas,

dispositivos o componentes de cualquier tipo, que proporciona una
comunicación de distintos niveles produciendo el intercambio de
información.

Página 15
● Ventana: Interfaz gráfica propia de un sistema operativo.

● Puntero del mouse: Representación de la posición del mouse en la
pantalla del computador y que es controlado por el usuario.
● Botones: Controles que al ser activados disparan una funcionalidad
del sistema, como, generar reporte, editar, actualizar, enviar, etc..
● Slider o control deslizador: Control tipo deslizador para manejar
cierta funcionalidad del sistema otorgándole mayor o menor intensidad.
● Animación: Secuencia de imágenes que son reproducidas en un
determinado intervalo de tiempo.
● Tablas: Organizan con arreglo a un formato de filas y columnas, similar
al de una hoja de cálculo.
● Roles: Jerarquía de control visual y de edición de datos del sistema.
● Inicio de Sesión: Nos permite conservar información sobre un usuario
al pasar de una página a otra.
● Menú:Conjuntos de opciones o posibilidades que se le presentan al
usuario.
● Formulario: Permite al usuario introducir datos los cuales son
enviados a un servidor para ser procesados.
De Tecnología:
● Actualizar o refrescar el navegador: Recargar el sistema mediante la

tecla F5 (Windows / Mac / GNU/Linux)
● Memoria caché del navegador: Es la memoria de que dispone el
navegador de internet para procesos internos.
Resumen
En el presente documento se describe la información sobre las características
del producto de software, interfaces del usuario, interfaces del sistema,
características de los usuarios, descripción de los requerimientos funcionales,
no funcionales y del sistema, los cuales se representarán mediante el
siguiente formato:
SRA
ERS – Especificación de requisitos de Software
Código Nombre Fecha Grado Necesidad
Referencia Nombre del Requerimiento Fecha de Importancia del
de Especificació requerimiento

Página 16
Requerimient
n
o
Descripción Descripción del Requerimiento
Entradas Fuente Salida Destino Restricciones
Entradas del
Fuentes de Salidas del Donde se Restricciones a
Requerimient
las entradas requerimiento lleva la salida tener en cuenta
o
Descripción detallada de las actividades que realiza el
Proceso
requerimiento.
Efecto
Efectos generados a otros procesos o sistemas, si es el caso.
Colateral
Código:
RF: Requerimiento funcional
RFN: Requerimiento no funcional
RI: Requerimiento de interfaz
1.1 DESCRIPCIÓN GENERAL

1.1.1 Perspectiva del producto
El sistema SRA será un producto diseñado para trabajar en entorno web, lo

cual permitirá su utilización de forma dinámica, además será independiente
por lo cual no interactúa con otros sistemas.
El sistema registrará la asistencia de los colaboradores, el súper usuario

podrá extraer una base en excel del control de la asistencia de los
colaboradores como dando un seguimiento y control de faltas , para poder
validar los pagos mensuales .
1.1.2 Funcionalidad del producto
El sistema SRA comprenderá los siguientes procesos:
a. Inicio de sesión.
b. Formulario de asistencia.
c. Reporte de asistencia.
1.1.3 Modelamiento de Casos de uso de SRA:
➢ Caso 1: Acceso al Sistema (SRA)

Página 17
Descripción: Permite el ingreso al sistema con el acceso correspondiente.
Actores: Trabajador proporciona información, previa a una validación que se

trata de un usuario autorizado del subsistema con su clave respectiva.
Precondiciones: El sistema debe estar conectado al servidor de la BD para

que se pueda almacenar la información, de la misma manera el usuario
autorizado se debe haber conectado al sistema para que se pueda generar la
información que el usuario requiera.
Flujo Normal:
1. El actor ingresa su código de identificación único.

2. El sistema presentará un mensaje de éxito.
Flujo Alternativo: Si en el sistema de empleados no se encuentra el id

presentará un mensaje de error.
Postcondiciones: La información registrada en la Base de Datos se

actualizará.
➢ Caso 2: Registrar Asistencia

Página 18
Descripción: Ingresado en el sistema generar reporte de entrada, salida e

historial de asistencia del personal.
Actores: Trabajador proporciona información, previa a una validación que se trata

de un usuario autorizado del subsistema con su clave respectiva.
Precondiciones: El sistema debe estar conectado al servidor de la BD para que

se pueda almacenar la información, de la misma manera el usuario autorizado se
debe haber conectado al sistema para que se pueda generar la información que el
usuario requiera.
Flujo Normal:
1. El actor genera su reporte de entrada en el sistema.
2. El sistema presentará un mensaje de éxito con el registro de entrada.
3. Hacer el mismo procedimiento para registrar la salida.
4. El sistema tiene una opción para ver su asistencia semanal, quincenal y
mensual.
Flujo Alternativo: Si en el sistema de empleados no se registra entrada/salida

presenta un mensaje de error.
Postcondiciones: La información registrada en la Base de Datos se actualizará.
➢ Caso 3: Generar Reportes de Asistencia.

Página 19
Descripción: Este caso de uso pretende generar el Reporte de ingreso y

salida del trabajador permitiendo la verificación de los días laborados.
Actores: Supervisor
Precondiciones: El sistema debe estar conectado al servidor de la BD para

que se pueda verificar la información, de la misma manera el usuario
autorizado se debe haber conectado al sistema para que pueda generar la
información requerida.
Flujo Normal:
1. El actor selecciona la opción de generar reporte.
2. El sistema presenta una tabla de datos con el listado de los
empleados y un panel de control de acción con el botón de filtrar.
3. Al hacer esto el sistema generará el reporte en un Excel.
4. Hacer clic en Aceptar para que se guarde el reporte en su
Computadora.
Flujo Alternativo: Si en la filtración de lo requerido se genera un error, se

notificará al actor mediante un mensaje.
Postcondiciones: La información requerida la obtendrá el supervisor.
1.1.4 Características de los usuarios
Tipo de usuario Colaborador

Página 20
Formación nivel secundaria completa ,estudios técnico o estudios

superiores
Habilidades Conocimiento básico a intermedio sobre página web y
office
Actividades Ingresa a marcar asistencia
Tipo de usuario Supervisor (super usuario)

Formación Estudios Superior o tecnicos
Habilidades Conocimiento intermedio office y conocimiento básico
sobre página web
Actividades Ingresa a marcar asistencia
Extrae una base de asistencia de sus colaboradores
Tipo de Usuario Soporte Páginas web.

Formación Ingeniero de sistemas.
Habilidades Conocimiento avanzado sobre programación web y
verificación de actualizaciones.
Actividades Mantenimiento del sistema.
1.1.5 Restricciones
● El sistema tendrá un entorno accesible y amigable para poder
realizar los registros.
1.1.6 Suposiciones y dependencias

● Compatible con todos los navegadores web
● El sistema será multiplataforma
1.1.7 Evolución previsible del sistema
● Implementación a futuras actualizaciones o mejoras del sistema

● Implementación a futuras colaboraciones con sistemas internos de la
empresa

Página 21
1.2 REQUISITOS ESPECÍFICOS

● R1: Permitir la autenticación de los usuarios.
● R2: Permitir a los colaboradores marcar la asistencia.
● R3: Gestionar reportes (exportar reporte)
1.2.1 REQUISITOS COMUNES DE LAS INTERFACES

1.2.1.1 Interfaces de usuario
Debe ser responsivo para las distintas resoluciones de pantalla, sin
embargo, no debe mostrarse en dispositivos móviles. El estilo de colores
debe cumplir el manual de estilos de la empresa, de igual manera con la
fuente.
El usuario previamente debe tener su cuenta de usuario en el sistema

para poder acceder. En caso de que no ingrese correctamente el
USUARIO o el PASSWORD se desplegará un mensaje de datos
incorrectos.
Una vez ingresado los datos en la pantalla de asistencia, se mostrará
una imagen agradeciendo su registro y deseando una excelente jornada
laboral.
1.2.1.2 Interfaces de hardware

● Pantalla: Para que el usuario visualice el ingreso de sus
datos.
● Ratón: Para que el usuario se desplace alrededor
del sistema.
● Teclado: Para que el usuario pueda digitar sus datos.
● Impresora: Para que el administrador del sistema pueda
imprimir sus reportes.
1.2.1.3 Interfaces de software

Navegadores web (Mozilla Firefox, Google Chrome, Opera, Microsoft
Edge, etc)
1.2.1.4 Interfaces de comunicación

Comunicación con los servidores de la empresa para la exportación de
los reportes y el almacenamiento de la información. La interfaz del
sistema desarrollado en PHP, HTML5, JS y CSS se comunicará con la
base de datos a través de phpMyAdmin.
1.2.2 REQUISITOS FUNCIONALES

El SRA proveerá facilidad de acceso para el registro de sus asistencia a los
colaboradores y así acceso a la información para el manejo de reportes.

Página 22
1.2.2.1 Ingreso a la aplicación

SRA
RF 2.2.1.1 Acceso al sistema 16/04/2021 Esencial
Descripción El sistema debe permitir ingresar por medio del protocolo HTTPS
Usuario y El ingreso solo lo
Contraseña realiza el usuario con
del los permisos y/o
Pantalla de Pantalla de
colaborador Red credenciales
logueo asistencia
necesarias y no se
abrirá desde
dispositivos móviles.
El sistema solicita un nombre de usuario y un password o contraseña
en la pantalla de logueo del sistema y si coinciden con las
Proceso
credenciales almacenadas en la Base de Datos se hará el ingreso a la
pantalla de asistencia..
Efecto
El mal ingreso de las credenciales mostrará una pantalla de error
Colateral
1.2.2.2 Administración de asistencia

SRA
Marcar asistencia en el
RF 2.2.2.1 14/04/2021 Esencial
sistema
El sistema debe permitir marcar asistencia una vez que haya sido
Descripción
logueado
Cada usuario debe
Hora de Botón de Pantalla de Base de
marcar una entrada y
ingreso ingreso asistencia Datos
una salida
El sistema tiene la opción de marcar la entrada y salida del
Proceso colaborador para ello tomará almacenará la hora en la que ha sido
registrada su entrada al sistema.
Efecto
No marcar entrada y salida podría reflejar incidentes en sus honorarios
Colateral

Página 23
1.2.2.3 Administración de reporte

SRA
Descargar reporte de
RF 2.2.3.1 asistencia de los 14/04/2021 Esencial
colaboradores
El sistema debe permitirle al usuario administrador del sistema
Descripción
descargar los reportes de cada colaborador
Archivo con
Registro de
Botón de formato XLS Archivos Solo el administrador
asistencia
descarga de descargado locales del podrá descargar los
por
asistencia en el equipo administrador reportes
colaborador
local
El programa deberá almacenar todos las asistencias marcadas por los
colaboradores, el usuario administrador podrá descargar los reportes
Proceso
guardados en la base de datos, los reportes se mostrarán separados
por colaborador
Efecto No marcar asistencia de los colaboradores implica que el registro no
Colateral sea llenado
1.2.3 REQUISITOS NO FUNCIONALES

1.2.3.1 Requisitos de rendimiento
● Se requerirá un sistema de respuesta rápida, pero ello dependerá del

procesador o la tarjeta de video y del tráfico de red del servidor de la
empresa.
● El sistema garantizará a los usuarios un desempeño en cuanto a los
datos almacenados en el sistema ofreciéndole una confiabilidad a esta
misma.
1.2.3.2 Seguridad
● Acceso seguro al sistema se debe emplear técnicas criptográficas

para la encriptación de las contraseñas, en este sentido la información
almacenada o registros realizados podrán ser consultados y
actualizados permanente y simultáneamente, sin que se afecte el
tiempo de respuesta.
● El sistema garantizará a los usuarios una seguridad en cuanto a la
información que se procede en el sistema, permitiendo el registro de

Página 24
la información al personal autorizado con la intención de consultar los

datos pertinente para cada usuario.
1.2.3.3 Fiabilidad
● El sistema debe tener una interfaz amigable de uso intuitivo y sencilla.
● La interfaz de usuario debe ajustarse a las necesidades del sistema.
1.2.3.4 Disponibilidad
● El sistema deberá estar disponible en los horarios de la jornada
laboral que corresponde a cada usuario, fuera de ello el sistema lo
registrará como una brecha de seguridad.
1.2.3.5 Mantenibilidad
● El mantenimiento del sistema se realizará de manera trimestral.
● El sistema deberá de tener un manual de instalación y manual de
usuario para facilitar los mantenimientos que serán realizados por el
administrador.
1.2.3.6 Portabilidad
● En la fase de producción se definirá el porcentaje de componentes
dependientes del servidor, el porcentaje de código dependiente del
servidor, el uso de un determinado lenguaje por su portabilidad y de
determinados compiladores o sistemas operativos para el mejor
desempeño.
1.2.4 Otros requisitos

La información que maneje el sistema debe estar sujeta a las normas y
políticas de las empresa.
2 PLAN DE GESTIÓN DE CALIDAD

2.1 ALCANCE DE LAS PRUEBAS
2.1.1 Elementos de pruebas

Definiremos el alcance de las pruebas en módulos, no todos los componentes serán
probados, escogimos como herramienta a SonarQube y SonarLint que permite
realizar análisis estático de código fuente de manera automática, buscando
patrones con errores, malas prácticas o incidentes, base un análisis de riesgos
realizado de manera previa, debemos tener en cuenta las variables tales como el
impacto que podría ocasionar, si falla una funcionalidad y la probabilidad de que
falle en un entorno de producción.

Página 25
Por lo tanto, son de Alto nivel por las operaciones que deben desarrollarse como las
pruebas a realizar:
● Detección de código duplicado.

● Pruebas unitarias y falta de comentarios.
● Complejidad ciclomática, alto acoplamiento.
● Tamaño de archivos de código.
● Tamaño de métodos.
● No adecuación a estándares y convenciones de código.
● Vulnerabilidades conocidas de seguridad.
Un listado de las pruebas que se realizarán “Desde el punto de vista del Usuario”.
No es una descripción técnica del software sino sus características y
funcionalidades que realizará, se incluirán tanto los nuevos requerimientos como los
modificados.
2.1.2 Nuevas funcionalidades a probar.
El sistema de información posee 2 roles de usuario (Trabajador - Supervisor) de los

cuáles cada uno podrá tener.
Rol Usuario
➔ Ingreso de usuarios (Trabajador - Supervisor)
Por medio de la validación de 2 campos, (usuario, contraseña) el sistema

generará una advertencia cuando los datos ingresados no son los mismos
que contiene la base de datos en la tabla usuarios.
Si la información ingresada es correcta, permitirá el acceso al portal y

redirigirá a la página de información personal del usuario.
(Imagen de Logueo)
➔ Visualización de información Personal (Trabajador - Supervisor)
El usuario podrá visualizar la información registrada en la base de datos

como datos personales y tendrá la posibilidad de modificar algunos de ellos.
(Imagen de información de usuario)

Página 26
➔ Visualización de ventana de ingreso y salida de asistencia (Supervisor -

Trabajador)
Este módulo provee la información de los horarios laborados del usuario en

un periodo vigente.
(Imagen de Asistencias )
➔ Visualización de asistencia (Trabajador)
Debe coincidir con lo almacenado en la base de datos a través de la

funcionalidad de ingreso y salida de asistencia por parte del Supervisor. Se
visualizará por una cantidad de cortes que tendrá el periodo de trabajo.
(Imagen de botones de ingreso y salida de asistencia)
➔ Visualización de eventos (Calendario) (Supervisor - Trabajador)
El usuario tendrá la posibilidad de visualizar los diferentes eventos de trabajo

que proponga la empresa a los cuales el trabajador pueda ingresar.
(Imagen de su cronograma de trabajo cambiado o habitual por parte de la

empresa)
➔ Ingreso de horarios de trabajo (Supervisor)
El supervisor podrá ingresar los horarios de trabajo para cada uno de los
empleados a los cuales les asignará el turno y horario de trabajo. Esta
información debe quedar almacenada en la base de datos, de tal manera que
el Trabajador pueda visualizarlo a través de la funcionalidad “Visualización de
Horarios”
(Imagen de cronograma de trabajo)

Página 27
➔ Cambio de Clave (Supervisor- Trabajador)
Mediante la validación de la clave actual, el trabajador podrá cambiar la clave

de acceso al portal WEB.
(Imagen de cambio de clave)
2.1.3 Pruebas de regresión
La prueba de regresión consiste en probar un sistema que ha sido analizado

previamente para asegurar que no se haya introducido algún tipo de defecto como
resultado de cambios realizados. ( ISTQB, 2017).
● Identificar errores introducidos por la combinación de programas probados

unitariamente.
● Determina cómo la base de datos de prueba será cargada.
● Utilizar la técnica down-top.
● Determinar que las modificaciones no han causado fallas o efectos adversos.
● Determinar que se cumplen con los requerimientos.
● Modificaciones menores selección de pruebas.
● Construir paquetes de pruebas de regresión, actualizarlas.
● La repetición de los casos de pruebas que se han realizado anteriormente y
están directamente relacionados con la parte del sistema modificada.
● La revisión de los procedimientos manuales preparados antes del cambio,
para asegurar que permanecen correctamente.
● La obtención impresa del diccionario de datos de forma que se compruebe
que los elementos de datos que han sufrido algún cambio son correctos.
2.1.4 Funcionalidades a no probar
Las pruebas No Funcionales se centran en aspectos muy importantes del

comportamiento del producto pero que no están relacionados con las funciones que
realiza el sistema.
● Pruebas de carga
● Pruebas de estrés
● Pruebas de volumen
● Pruebas de configuración
Página 28
● Pruebas de usabilidad
● Pruebas de seguridad
● Pruebas de resistencia
● Pruebas de escalabilidad
● Pruebas de recuperación
● Pruebas de mantenibilidad
2.2 PROCEDIMIENTOS PARA LAS PRUEBAS

Nuestro proyecto es escalable, sin embargo consideramos correcto usar una
metodología lineal o llamada también tradicional, debido a que después de la
primera entrega recién se procederá a trabajar por sprints. Para ello proponemos
las siguientes fases basándonos en RUP.
● Planificación de pruebas
● Diseño de pruebas
● Implementación de pruebas
● Evaluación de criterios de salida
● Cierre del proceso
El fin de dividirlo en fases es para poder cumplir con cierta funcionalidad del
software en cada una de las fases. Las fases de un proyecto de metodología
tradicional también pueden definir diversos niveles de abstracción, en el caso de
control de calidad se traduce en los diferentes tipos de prueba de acuerdo a la
profundidad o enfoque que se le quiera dar, en nuestro proyecto usaremos el
modelo V.

Página 29
2.2.1 Criterios de aceptación o rechazo
El SRA será entregada y posteriormente probada por el cliente DYNAMICALL, bajo

los siguientes criterios.
Criterio Descripción
Se aprobará el proyecto con un 100% de las pruebas ejecutadas
pero con un 90% de aceptación.
Esto quiere decir que el 90% de las pruebas deben ser exitosas y
Aprobado
sin errores.
En el restante 10% puede existir fallas de criticidad medias o bajas
pero no graves o alta.
En caso de ocurrir que el proyecto no cumpla con el nivel exigido,
Rechazado
el proyecto se rechaza completo en su etapa final.
Los errores resultantes del Testing de Aceptación se clasifican en distintos niveles

de criticidad.
Criticidad Descripción
Son eventos producto del mal funcionamiento del sistema
Alta
impidiendo continuar con su uso.
Son eventos graves que pueden no afectar el funcionamiento del
Media
sistema pero necesitan ser corregidos.
Es un aporte al sistema que mejora la funcionalidad de los
Baja
procesos.
Ninguno Indica que el evento no presenta ningún tipo de criticidad.
2.2.2 Criterios de suspensión
Los Casos de Prueba que fallaron tendrán un evento asociado a un estado donde
se reporta la incidencia/error.
❖ Los estados finales de un evento son:
Estado Evento
Satisfactorio Cuando se ejecuta un Caso de Prueba y no se produce
ningún error.
Pérdida de Vigencia Cuando un error que había sido reportado, ya no está

vigente, es decir, ya no tiene sentido corregirlo por
cambio en la funcionalidad.

Página 30
Cerrado Cuando se comprueba que el defecto ha sido corregido,

la falla que había sido reportada.
Sin valor de Este estado es asignado a un evento cuando no se

referencia para puede realizar la ejecución de un Caso de Prueba
comparar debido a que la funcionalidad que especifica el caso
aún no está desarrollada.
❖ Los estados intermedios de un evento que deben llegar a un estado final son:
Estado Evento
Pendiente Cuando el resultado de la ejecución del Caso de Prueba, se
produce un error.
Suspendido Cuando el error es reconocido como tal, pero por el momento

no se procederá a la corrección del mismo porque existen
otras tareas de mayor prioridad que deben realizarse.
No Asignado por el desarrollador: Cuando la incidencia asignada

corresponde al no le corresponde corregir, permitiéndole al jefe del proyecto
recurso asignarla al programador correspondiente.
No aplica Cuando el desarrollador o el jefe de proyecto interpretan que el

desarrollo error reportado no es tal.
Las posibles causas son: inconsistencia en la documentación,
factibilidad técnica, etc.
Cuando el analista de testing comprueba que el error ha sido

Cerrado corregido, es decir, vuelve a ejecutar el Caso de Prueba y ya
no se produce el error que había sido reportado.
Cuando el desarrollador ha corregido el error, es decir, vuelve

Corregido a ejecutar el Caso de Prueba y ya no se produce el error
reportado.
Cuando el desarrollador ejecuta el Caso de Prueba para

No se puedo
reproducir el error reportado y proceder a su corrección, pero el
Reproducir
mismo no se produce.
Cuando el jefe de proyecto asigna un evento a un

Asignado
desarrollador para que este corrija el error reportado.

Página 31
Como condición de criterio de aceptación, se considera que la solución a un

módulo son aceptables cuando, como resultado de la ejecución del “Test de
Aceptación” se encuentre una distribución en la criticidad de los errores, que sigan
los siguientes porcentajes respecto a la totalidad de los casos de prueba:
% sobre Totalidad de Casos de Prueba

Criticidad del Error
Alta 0%
Media 4%
Baja 6%
2.2.3 Criterios de reanudación
Los procesos de prueba se suspenderán y el desarrollador será contactado bajo las

siguientes circunstancias o criterios:
- Revisión de fallas básicas.

- Múltiples anomalías de alto nivel de prioridad (Crítico).
- Múltiples anomalías de nivel medio que no corresponden a las
especificaciones.
2.2.4 Roles del personal:
ROLES PARA LA GESTIÓN DE LA CALIDAD

Funciones del rol:
ROL N O1: ● Planificación de proyecto y definición de objetivos.
Jefe de Proyecto ● Reporte de vialidad.
● Coordinación de recursos.
Reporta a:
Cliente representantes de DYNAMICALL
Funciones del rol:
ROL N O2: ● Adaptar y diseñar el sistema de información para trabajar de forma
Analista de Sistemas más rápida y eficiente.
● Análisis y modelo de procesos y datos.
Reporta a:
Jefe de proyecto
ROL N O3: Funciones del rol:
● Diseñar la interfaz gráfica del sistema según los requerimientos del
Desarrollador
cliente.
Frontend y backend ● Configurar, administrar y mantener los sistemas de base de datos.
● Programar la funcionalidad del sistema en base a los requerimientos
Página 32
obtenidos.
Reporta a:
Jefe de Proyecto.
Funciones del rol:
● Planificación de la logística
● Verificar y validarla eficiencia de las pruebas.
ROL N O4 : Jefe de
Calidad Supervisa a:
Analista de pruebas.
Reporta a:
Jefe de Proyecto.
Funciones del rol:
● Implementar y ejecutar las pruebas con el Sonar.
● Definir los datos de pruebas.
ROL N O5 : Analista
● Documentar los incidentes.
de Pruebas
● Proporcionar informes al equipo del proyecto sobre cualquier
problema o mejora que el sistema pueda requerir.
Reporta a:
Jefe de Pruebas de calidad.
2.2.5 Matriz de responsabilidades:
Matriz Raci del Sistema Registro de Asistencia.
MATRIZ RACI DEL SISTEMA DE REGISTRO DE ASISTENCIA

ROLES
ID ACTIVIDADES Analista Dev.

Jefe de Jefe de Analista de
de Frontend
proyecto Calidad Pruebas
sistema y Backend
1 Identificar la necesidad de los usuarios A R C I I

2 Realizar la lista de requisitos por los usuarios C R A I/C I
3 Gestión de cronograma R C C A I/C
4 Elaboración de plan de gestión del software R A C C I
5 Programador C A R I/C C
6 Administrador de la BD I C R A/I C
7 Diseñador de la página web A R I C C
8 Analista y tester de software A C/I C C R

Página 33
9 Auditoría, monitoreo y revisión del software C R I I/C I

10 Rectificación de fallas detectadas en el Software I C R I C
11 Desarrollo del Manual de Usuario C R I/A A C
12 Capacitación del Uso del Software A C R C/I C
2.2.6 Cronograma:
El cronograma del Sistema Registro de Asistencia.
NOMBRE DE TAREAS DURACIÓN COMIENZO FIN

Sistema de registro de asistencia 36 días lun 17/05/21 lun 05/07/21
Fase de Pruebas 28 días lun 17/05/21 mié 23/06/21
Reunión con el equipo de trabajo 2 días lun 17/05/21 mar 18/05/21
Identificación de la herramienta de pruebas 3 días lun 17/05/21 mié 19/05/21
Realización Plan de Pruebas 3 días lun 17/05/21 mié 19/05/21
Ejecución del plan de pruebas 12 días mié 26/05/21 jue 10/06/21
Pruebas de integridad a la BD 5 días mié 26/05/21 mar 01/06/21
Prueba de Funcionamiento 2 días mié 26/05/21 jue 27/05/21
Prueba de control de Seguridad y acceso 2 días mié 26/05/21 jue 27/05/21
Prueba de rendimiento 3 días mié 26/05/21 vie 28/05/21
Informe de Pruebas 3 días lun 14/06/21 mié 16/06/21
Confirmación de resultados 5 días jue 17/06/21 mié 23/06/21
Informe de resultados de Pruebas 2 días jue 24/06/21 vie 25/06/21
Base de los módulos 6 días lun 28/06/21 lun 05/07/21

Página 34
anexo MS del cronograma.
2.2.7 Premisas:
Para que el plan de pruebas se pueda llevar a cabo se debe tener:
➢ Disponibilidad de tiempo.
➢ Disponibilidad de recursos.
➢ Metodología de las pruebas
➢ Uso de herramientas
➢ Conocimiento de las pruebas por los integrantes del grupo.
Para que el plan de pruebas del SISTEMA DE REGISTRO DE ASISTENCIA se dé

por concluido se deben de cumplir las siguientes actividades.
Probar cada interfaz del sistema.

Probar logeo.
Probar ingreso y salida de asistencia.
Probar el botón registro de asistencias.

Página 35
2.2.8 Dependencias y Riesgos:
RIESGO PLAN DE CONTINGENCIA IMPACTO
Falta de capacitación al Capacitar al personal Página afectada por una mala

personal Reemplazar al personal antiguo. capacitación
Proyecto afectado por la

Mejorar el plan de pruebas
Tiempo de Prueba inconformidad del usuario que pueda
Análisis de las pruebas realizadas
manifestar
Errores en la ejecución del Volver a realizar las pruebas Área de pruebas, desarrollo y
plan de pruebas identificando los errores mantenimiento de Software
● Posibles dificultades en las disponibilidades de entorno.

● Pruebas que dependen de factores externos al proyecto.
● Disponibilidad del personal con conocimiento especializado en las
herramientas o en la funcionalidad específica que se desarrolla.
● Posibilidad que la idea no se cumpla.
2.3 RECURSOS Y HERRAMIENTAS DE PRUEBAS

2.3.1 Requerimientos de Entornos – Hardware
Los requerimientos de hardware que necesitamos es:
● Procesador Intel o AMD de 2 a 4 núcleos

● Memoria Ram 8GB
● CPU
● Disco duro
● Placa Base
● UPS o SAI(sistema de alimentación ininterrumpida)
● Monitor IPS Full HD de 21,5” con AMD
● Impresoras
2.3.2 Requerimientos de Entornos – Software
Los requerimientos de software que necesitamos para la ejecución de nuestras

pruebas de calidad son las siguientes:
● Servidor web: Xampp vr.3.3.0
● Windows 10

Página 36
● PHP 8.0.6
● Navegadores Web
● HTML
● JS
● CSS
● SonarQube
● SonarLint
● PHPUnit
● PHPLint
2.3.3 Herramientas de Pruebas Requeridas
El equipo de pruebas utilizara las herramientas de medición para el SRA, son el

paquete SONAR (SonarQube, SonarScanner, Sonarlint) y PHPUNIT con las
librerías de PHPUnit (composer junto a PHPLint) , a continuación los detalles.
2.3.3.1 SONARQUBE:
Plataforma para evaluar código fuente y la calidad del mismo. Es software

libre y usa diversas herramientas de análisis estático de código fuente como
Checkstyle, PMD o FindBugs para obtener métricas que pueden ayudar a
mejorar la calidad del código de un programa.

Página 37
● SONARSCANNER: Herramienta complementaria de SonarQube que nos

permite escanear el código fuente y poder cargar el proyecto a la plataforma,
es el intermediario entre CÓDIGO-PLATAFORMA.
● SONARLINT: SonarLint es una extensión IDE que le ayuda a detectar y
solucionar problemas de calidad mientras escribe código. Como un corrector
ortográfico, SonarLint garabatea fallas para que puedan corregirse antes de
enviar el código.
2.3.3.2 PHPUnit:
PHPUnit es un framework para implementar pruebas unitarias en lenguaje

PHP o TDD - Desarrollo Guiado por Pruebas. Es decir, es un framework que
nos ayuda a probar nuestro código realizando pruebas unitarias. Mediante la
clase de nuestro código y la clase de pruebas.

Página 38
PARTE III: DESARROLLO CON HERRAMIENTA DE

MEDICIÓN
1 PLAN DE PRUEBAS DE SOFTWARE:
1.1 Enfoque de pruebas
En este capítulo vamos a ver los tipos de pruebas según se realizan dentro del ciclo
de vida del software.
Existen diferentes modelos de desarrollo de software. Entre ellos tenemos métodos

clásicos como pueden ser el modelo en cascada, el modelo general en V o métodos
más populares hoy en día como pueden ser metodologías ágiles, programación
extrema, etc. Cada uno de estos métodos tiene una vía de trabajo diferente,
indicando cómo se tiene que trabajar durante la vida del proyecto.
Las pruebas están dentro de estos modelos de maneras muy diferentes. Por
ejemplo, dentro del modelo en cascada las pruebas se ejecutan al final del proyecto
y dentro del modelo en V se realizan en los diferentes niveles de desarrollo.
1.5.1 Modelo en V:
Se va a utilizar el modelo en V como referencia para ver cómo se integran las

pruebas dentro del ciclo de vida del software. En este modelo las tareas de
desarrollo y pruebas tienen la misma importancia.

Página 39
1.5.2 Niveles de prueba:
Para cada nivel de desarrollo se define un nivel de prueba. Dentro de cada nivel de
prueba el probador debe asegurarse de que los resultados cumplen con la
verificación y la validación del software.
2 HERRAMIENTA DE CALIDAD DEL PRODUCTO (SonarQube)
Las herramientas de medición descritas con anterioridad para el SRA, deberá ser
capacitado en su uso y procedimiento a continuación el detalle.
2.1 Instalación y descripción de uso del SonarQube:
● Paso 1: Descargar SonarQube

Página 40
● Paso 2: Iniciar el servicio StartSonar.bat para levantar la plataforma local.
● Paso 3: Loguearnos en la plataforma “Localhost:9000”

Página 41
● Paso 4: Crear un nuevo proyecto “Add project/Manually/ *ingresar un

nombre*.
● Paso 5: Crear el archivo sonar-project.properties en nuestra carpeta raíz,

este archivo debe contener el nombre del proyecto que ingresamos en el
paso 4.

Página 42
● Paso 6: Descargamos SonarScanner, descomprimimos y copiamos el

contenido en la carpeta de SonarQube.
● Paso 7: Añadimos la variable de entorno “sonar-scanner\bin\...:”

Página 43
● Paso 8: Iniciamos el servicio “sonar-scanner.bat” mediante consola.
● Paso 9: Analizamos el resultado final en la plataforma identificando errores,

bugs y vulnerabilidades de seguridad.

Página 44
3.2 Leyenda de la herramienta:
● Tipos de problemas: Existen 3 tipos de problemas

1. Bug: un error de codificación que romperá su código y debe
corregirse de inmediato.
2. Vulnerabilidad: un punto en su código que está abierto a ataques.
3. Code Smell: un problema de mantenimiento que hace que su código

sea confuso y difícil de mantener.

Página 45
4. Security Hubspot: Un Security Hotspot destaca un fragmento de

código sensible a la seguridad que el desarrollador debe revisar. Tras
la revisión, encontrará que no existe ninguna amenaza o debe aplicar
una solución para proteger el código .
2.3 Gravedad del problema:

Cada problema tiene una de cinco grados de gravedad:
● Bloqueador
Error con una alta probabilidad de afectar el comportamiento de la aplicación

en producción: pérdida de memoria, conexión JDBC no cerrada, El código
DEBE ser reparado inmediatamente.
● Crítico
O un error con baja probabilidad de afectar el comportamiento de la

aplicación en producción o un problema que representa un defecto de
seguridad: bloqueo de captura vacío, inyección SQL, El código DEBE ser
revisado inmediatamente.
● Importante
Defecto de calidad que puede afectar en gran medida la productividad del

desarrollador: código descubierto, bloques duplicados, parámetros no
utilizados
● Menor
Defecto de calidad que puede afectar ligeramente la productividad del

desarrollador: las líneas no deben ser demasiado largas, las declaraciones
de "cambio" deben tener al menos 3 casos.
● Info
Ni un error ni un defecto de calidad, solo un hallazgo.

Página 46
Estados: Después de la creación, los problemas fluyen a lo largo de un ciclo de

vida, tomando uno de los cinco estados posibles:
● Abierto: establecido por SonarQube en problemas nuevos

● Confirmado: se configura manualmente para indicar que el problema es
válido
● Resuelto: configurarlo manualmente para indicar que el siguiente análisis
debe cerrar el problema
● Reabierto: configurado automáticamente por SonarQube cuando un
problema resuelto no se ha corregido realmente
● Cerrado: configurado automáticamente por SonarQube para problemas
creados automáticamente.
Resoluciones: Los problemas cerrados tendrán una de dos resoluciones:
● Solucionado: se configura automáticamente cuando un análisis posterior

muestra que el problema se ha corregido o que el archivo ya no está
disponible (eliminado del proyecto, excluido o renombrado)
● Eliminado: se establece automáticamente cuando la regla relacionada ya no
está disponible. Es posible que la regla no esté disponible porque se eliminó
del Perfil de calidad o porque se desinstala el complemento subyacente.
● Los problemas resueltos tendrán una de dos resoluciones:
● Falso positivo: configurar manualmente
● No se arregla: configurar manualmente
Mejora de la calidad:
Como podemos observar en la siguiente imagen, después de toda la leyenda

existe un apartado llamado “Cómo solucionarlo?” es ahí donde nos da los
parámetros y recomendaciones para que el código deje de presentar dicho
problema

Página 47
3 HERRAMIENTA DE PRUEBAS UNITARIAS (PHPUnit)

3.1 Instalación y descripción de uso del PHPUnit:
● Paso 1: Para la instalación de PHPUnit debemos tener PHP instalada,

verificar la versión de PHP que poseemos, para poder descargar con la
versión de PHPUnit indicado para dicha versión, cabe resaltar que por cada
vr. de PHP hay una vr. de PHPUnit compatible.(aunque se recomienda
siempre tener las últimas versiones actualizadas.)
● Paso 2: Ahora añadimos la variable de entorno en el sistema, en path

agregamos la siguiente variable “ c:\xampp\php\php.exe”

Página 48
● Paso 3: Ahora para instalar PHPUnit vamos a la Url.

https://phpunit.de/getting-started/phpunit-9.html y visualizamos que hay 2
formas de poder instalar el PHPUnit.
● Paso 4: Ahora instalaremos el Composer(herr. enfocada al uso de PHP) para ello

iremos a descargar al siguiente Url. https://getcomposer.org/ luego
instalamos.
● Paso 5: Luego verificamos la versión del composer instalada.

Página 49
● Paso 6: Ahora ejecutamos el composer para la instalación de PHPUnit, para

ello creamos una carpeta y desde el cmd ejecutamos el siguiente código:
composer require phpunit/phpunit --dev
● Paso 7: Ahora vamos a crear una carpeta y dentro de ella 2 carpetas

llamadas SCR, Tests y vendor y el composer.jason
● Paso 8: Ahora dentro del archivo composer.jason realizamos el siguiente

código para la auto carga de los archivos del dev. y de pruebas.

Página 50
● Paso 9: Ahora ejecutamos otro comando composer de autocarga para

obtener las actualización del archivo desarrollador y archivo de prueba con el
comando: composer dumpautoload.
● Paso 10: Realizaremos ejemplos, nuestro archivo es ejem, y el de pruebas

es ejemTest, recordemos que las pruebas unitarias deben estar dentro de
una clases y serán evaluadas el resultado esperado con el resultado real.
con el comando indicado en imagen.

Página 51
● Paso 9: ejecutamos la siguiente línea de comando vendor/bin/phpunit tests

esta línea de comando es para hacer el llamado de phpunit en el archivo de
prueba, la prueba muestra en el primero nos muestra una letra “E”, que
significa error y un punto “.” para una aceptación.

Página 52
3.2 Leyenda de herramienta:

Tipos de problemas: que muestra el PHPUnit.
Signo de punto “.”: Se imprime cuando la prueba es exitosa.
F: Se imprime cuando una aserción falla mientras se ejecuta un método de

prueba.
E: Se imprime cuando ocurre un error mientras se ejecuta un método de

prueba.
R: Se imprime cuando una prueba se ha marcado como riesgosa ( Pruebas

Riesgosas).
S: Se imprime cuando la prueba ha sido omitida.
I: Se imprime cuando la prueba se marca como incompleta o aún no

implementada.
3.3 Gravedad del Problema:

Por defecto PHPUnit instalará un gestor de errores que convierte los siguientes
errores en excepciones:
● E_WARNING
● E_NOTICE
● E_USER_ERROR

Página 53
● E_USER_WARNING
● E_USER_NOTICE
● E_STRICT
● E_RECOVERABLE_ERROR
● E_DEPRECATED
● E_USER_DEPRECATED
4 PRUEBAS UNITARIAS A 2 PROCESOS: Evaluación

4.1 PHPUnit ejemplo
➔ PHPUNIT ejemplo:
➔ En este archivo del desarrollador, tenemos la clase saludo, con una función
que retorna un string.
➔ En este archivo para realizar las pruebas, donde hacemos el llamado

de la clase que se desarrolló. y haciendo uso de Framework de
PHPUnit.

Página 54
➔ Como primera instancia podemos observar el funcionamiento de las clases

creadas con éxito mediante el símbolo de un “check” en la consola o
terminal, como también nos puede exportar con el mismo check en diferentes
formatos.
➔ como también nos puede exportar con el mismo check en diferentes

formatos. Como también revisar la documentación de PhpUnit testdox.
➔ Asimismo es necesario mencionar que para poder ejecutar las diferentes

herramientas de testeo que nos proporciona “PHPUnit” debemos tener
instalado y en ejecución el xdebug de php en nuestro ordenador.

Página 55
➔ “PHPUnit” nos permite generar reportes de nuestras pruebas realizadas, a

través de las cuales podemos observar las métricas mediante un dashboard,
el cual mostrará:
◆ Coverage Distribution
◆ Complexity
◆ Project Risks
◆ Insufficient Coverage
➔ Como podemos observar nos presenta un alto grado de funcionalidad y corto

tiempo de ejecución, indicando en base a colores.

Página 56
➔ También nos permite poder visualizar nuestro código en caso haya algún
error, todo esto gracias al xdebug de php que anteriormente debimos poner
en ejecución.
● ahora le mostramos la cobertura en forma de dashboard.

Página 57
● Mismo ejemplo en SonarQube: En este caso SonarQube no detectó ni un

bug, vulnerabilidad o problemas de seguridad.
En este caso SonarQube no detectó ni un bug, vulnerabilidad o problemas de

seguridad.

Página 58
Sin embargo, que no haya detectado ni un error no significa que haya algún
inconveniente con el código, lo que nos detecta SonarQube es que el fragmento de
código no puede ser cubierto por la herramienta.
4.2 SonarQube ejemplo sra:
➔ Ingreso al portal del sistema de Registro de Asistencia. ingresamos usuario y

password.
➔ con la información del usuario, marcamos el ingreso o salida de la asistencia

diaria.

Página 59
➔ muestra del codigo en el que se obtiene el registro de asistencia del usuario.

Página 60
➔ En dicha prueba nos indica muestra una recomendación sobre nuestra

conexión de host.
➔ La carga de archivos de nuestro proyecto.

Página 61
➔ Aquí nos muestra líneas de código que el SonarQube no examina, en este

caso es la conexión a la base de datos.
5 Benchmarking:
Cuadro comparativo entre el sonarqube y el phpunit.
ATRIBUTOS SONARQUBE PHPUNIT
PRUEBAS UNITARIAS x
PRUEBAS FUNCIONALES x
PRUEBAS NO FUNCIONALES x
PRUEBAS DE ACEPTACIÓN
PRUEBAS ESTÁTICAS
CAJA NEGRA x x
CAJA BLANCA

Página 62
3 Entregables de pruebas
Cuando el cliente apruebe la entrega de la solución y su funcionamiento, mediante
las cartas de aceptación, será responsable del uso de la solución.
● Formato de casos de pruebas:
<Nombre caso de prueba> <Código del CP>

Descripción: <Descripción del caso de prueba>
Prerrequisitos: <Enumerar los prerrequisitos para la prueba>
Pasos: <Pasos generales para la prueba, basados en los escenarios de los casos de uso, si existen.>
Resultado esperado: <Resultado esperado de la prueba>
Resultado obtenido: <Resultado obtenido de la ejecución del caso de prueba>
Evaluación de la prueba: <Estado obtenida de la ejecución del caso de prueba>
● Plan de pruebas unitarias: (PPU_(PROY)_Plan_Pruebas_Unitarias)

● Plan de pruebas funcionales:(PPF_[PROY]_Plan_Pruebas_Funcionales)
● Plan de pruebas de Integración:(PPI_(PROY)_Plan_Pruebas_Integracion)
CONCLUSIONES Y RECOMENDACIONES
BIBLIOGRAFÍA:
● Desarrollo De Una Aplicación Web Para La Mejora Del Control Y Registro De

Asistencia Del Personal En La Asociación De Servicios De Limpieza Eficaz
Asodesef-INTRIAGO PÉREZ DAYSI PRISCILLA -GUAYAQUI-Ecuador,
OCTUBRE 2020
● IMPLEMENTACIÓN DE UN SISTEMA WEB PARA REDUCIR EL TIEMPO
EN LA GESTIÓN Y CONTROL DE ASISTENCIA, PERMISOS Y LICENCIAS
DE VACACIONES EN LA ESCUELA SUPERIOR MILITAR DE AVIACIÓN
“COSME RENNELLA BARBATO”, SALINAS-ZORAIDA ESTEFANIA
ALVARADO FRANCO-LA LIBERTAD – ECUADOR 2019
Referencia
Referencia Título Ruta Fecha Autor
ERS 3.0 ERS 3.0_standalone_v1.2 --- 17/12/2018 ---
IEEE 830 Especificación de Requisitos --- 22/10/2008 ---
Página 63
según el estándar
de IEEE 830
ANEXOS SUGERIDOS:
1 PROJECT CHARTER
Datos
Empresa / Organización DynamiCall

Proyecto Sistema de registro de asistencia
Fecha de preparación 16/04/21
Cliente
Enrique Beltrán Cornejo
Patrocinador principal Alarcón Castillo, Carlos Franco

Sánchez López, Fabian Leonel
Tasayco tuanama, Luis fernando
Vásquez Medina, Ana Kelly
Gerente de proyecto Vásquez Medina, Ana Kelly
Propósito y justificación del proyecto
● Delimitar las especificaciones funcionales y no funcionales del sistema web

SRA, el cual permitirá gestionar la información detallada de cada uno de los
colaboradores mediante el registro de ingresos, de los mismos.
● Evaluar los errores y defectos que pueden existir en un sistema, con el fin
de corregirlos.
● Verificar que los validadores de datos funcionen y limiten el ingreso de
información, para que no se puedan ingresar datos que no están
permitidos.
● El sistema tendrá que pasar evaluaciones de aceptación de los
colaboradores y supervisores.
● Con el requisito de optimizar los procesos de recursos humanos para
validar las asistencias de nuestros colaboradores.

Página 64
Descripción del proyecto y entregables

El proyecto consiste en la implementación de un sistema que permita el registro
de asistencias con el reporte de las mismas para facilitar el reporte completo de
todos los ingresos y salidas en el horario laboral al asesor de los colaboradores,
en la empresa DynamiCall.
Los responsables del proyecto serán:
● Alarcon Castillo Carlos Franco - Backend testing
● Rojas Espinoza Juan Carlos - Desarrollador frontend
● Sánchez López Fabián Leonel - Administrador de base de datos
● Tasayco Tuanama , Luis - Desarrollador backend
● Vasquez Medina, Kelly - Analista de sistemas, líder del proyecto.
Como entregables tenemos:
● Ingreso al sistema mediante una interfaz web.
● Registro de ingreso de asistencias de los usuarios mediante un clic.
● Registro de salida de asistencias de los usuarios mediante un clic.
● Búsqueda de usuarios por rol correspondiente en el sistema
● Generar un reporte de las asistencias registradas
Requerimientos de alto nivel

Requerimientos del producto
El sistema deberá permitir al administrativo, jefe administrativo y

administrador del sistema iniciar sesión una vez ya esté registrado,
ingresando usuario y contraseña.
El sistema deberá permitir al administrativo, jefe administrativo y
administrador del sistema cerrar sesión.
El sistema deberá permitir al administrativo y jefe administrativo marcar
su ingreso, y salida del horario laboral. Siempre que se encuentre con inicio
de sesión.
El sistema deberá permitir al administrativo y jefe administrativo listar
sus horas de trabajo en rangos de fechas seleccionadas por él.
El sistema deberá permitir al administrativo y jefe administrativo imprimir su
lista de horas trabajadas.
Requerimientos del proyecto
Un gerente de proyecto
Aprobación del estudio de requerimientos en el área de RRHH
Aprobación de la inversión para la implementación del sistema
Aprobación de la evaluación de la cantidad de personal y los diferentes cargos
Entregar un informe mensual de las actividades realizadas, el cual será revisado y
aprobado por el jefe de recursos humanos.

Página 65
Objetivos
Objetivo Indicador de éxito
Alcance
Aprobación de todos los
● Cumplir con la elaboración de los entregables entregables por parte del
● Especificación de requerimientos directorio de la empresa.
● Plan de pruebas.
● Estudio de 2 herramientas de pruebas.
Cronograma (Tiempo)
El proyecto tendrá una duración de 5 meses a partir cumplir con los tiempos
del mes de marzo hasta julio del presente año. establecidos en el
cronograma.
Costo
5,000 PEN es el costo en la implementación del No exceder el presupuesto
sistema de registro de asistencias y reporte. del proyecto
Calidad
● Informe de plan de pruebas del proyecto. Aprobación de todos los
● Cumplir con los criterios de Aceptación. entregables.
● Benchmarking de las herramientas de prueba.
Premisas y restricciones
Para que el plan de pruebas se pueda llevar a cabo se debe tener:
➢ Disponibilidad de tiempo.
➢ Disponibilidad de recursos.
➢ Metodología de las pruebas
➢ Uso de herramientas
➢ Conocimiento de las pruebas por los integrantes del grupo.
Para que el plan de pruebas del SISTEMA DE REGISTRO DE ASISTENCIA se dé

por concluido se deben de cumplir las siguientes actividades.
Probar cada interfaz del sistema.

Probar logeo.
Probar ingreso y salida de asistencia.
Probar el botón registro de asistencias.
La restricción del sistema tendrá un entorno accesible y amigable para poder

realizar los registros.
Riesgos iniciales de alto nivel

Página 66
Retraso de en el desarrollo de los módulos del sistema

Fallos imprevistos en el sistema
Levantamiento de requerimientos incompleto
Problemas con los recursos humanos
Cronograma de hitos principales

Hito Fecha tope
Desarrollo del inicio de sesión 19/05/21
Desarrollo del cierre de sesión 28/0521
Desarrollo del método de marcaje de asistencia 04/06/21
Desarrollo del método para listar las horas trabajadas. 11/06/21
Desarrollo del método para imprimir la lista de horas 18/06/21
trabajadas.
Presupuesto estimado
Desarrollo del sistema de asistencias 5.000
Mantenimiento/actualización del 2.000
sistema de asistencias, con posibles
nuevas integraciones.
Lista de Interesados (stakeholders)

Nombre Cargo
CEO y Fundador
Enrique Beltrán Cornejo
Gianfranco Giuttari Claussi Gerente de Administración y

Finanzas
Carlos Basurto Yamani Gerente de TI
Maritza Puma Estrada Directora de Operaciones
Carolina Venegas Gala Gerente de Operaciones
Angélica Mesta Romero Gerente de Operaciones
Magaly Alvarado Caldas Gerente de Negocios
Ursula Valdez Calmet Sub Gerente de Control de Gestión
Requisitos de aprobación del proyecto
Acta de reconocimiento de prácticas pre-profesionales.

El análisis económico debe mostrar una rentabilidad adecuada frente a la
Página 67
propuesta de implementación.
Asignación del gerente de proyecto y nivel de autoridad

Gerente de proyecto
Nombre Cargo Departamento /

División
Carlos Basurto Gerente de TI área de TI
Yamani
Niveles de autoridad
Área de autoridad Descripción del nivel de autoridad

Decisiones de personal (Staffing) Gerente de TI
Gerente de Administración y Finanzas
Gestión de presupuesto y de sus Gerente de TI
variaciones Gerente de Administración y Finanzas
Decisiones técnicas Gerente de TI
Resolución de conflictos Gerente de TI
Ruta de escalamiento y limitaciones de Organigrama
autoridad
Aprobaciones
Patrocinador Fecha Firma
Carlos Basurto Yamani 19/05/21
Gianfranco Giuttari Claussi 28/05/21

Página 68
2 ESTRUCTURA DE DESGLOSE DE TRABAJO: EDT
EDT proyecto de sistemas de registro de asistencia
3 JMeter
Es una herramienta que facilita la gestión integral de los procesos de pruebas de
rendimiento, no obstante no es la única puesto que tenemos otras como: Micro
Focus LoadRunner, IBM RPT, SilkPerformer, WebLoad, NeoLoad, OpenSTA, otras.
‘Apache JMeter’ es una aplicación de código abierto, 100% basada en Java con una
interfaz gráfica de usuario. Está diseñada para analizar, medir el rendimiento y
cargar el comportamiento funcional de la aplicación web y la variedad de servicios.
Tipo de prueba

Página 69
· No funcional
Subconjunto
· Las pruebas de carga, las pruebas de estrés, las pruebas de picos, las
pruebas de resistencia y las pruebas de volumen son subconjuntos de las
pruebas de rendimiento.
JMeter se utiliza principalmente para:
● probar aplicaciones web

● aplicaciones FTP
● pruebas funcionales
● conexiones de bases de datos JDBC
● servicios web
● conexiones TCP genéricas
● procesos nativos del sistema operativo
Objetivo se realizan las actividades mencionadas
· Para obtener métricas de rendimiento precisas en su servidor web.
EJEMPLO

Página 70

Página 71

Página 72

G05 - Plan de Pruebas de SRA-ejm

Cargado por

Copyright:

Formatos disponibles

G05 - Plan de Pruebas de SRA-ejm

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

G05 - Plan de Pruebas de SRA-ejm

Cargado por

Copyright:

Formatos disponibles

FACULTAD DE INGENIERÍA

ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS

SISTEMA DE REGISTRO DE ASISTENCIA - ANÁLISIS DE

Alarcon Castillo, Carlos Franco

Rojas Espinoza, Juan Carlos

Sánchez López, Fabián Leonel

Tasayco Tuanama, Luis Fernando

Vasquez Medina, Ana Kelly

Acosta Ticse, Deisy Lizbeth

Plan de Pruebas del Sistema de Registro de Asistencia

GIRO DEL NEGOCIO 6

PROCESOS PRINCIPALES DE LA EMPRESA 8

PLANEAMIENTO ESTRATÉGICO DE TECNOLOGÍAS DE INFORMACIÓN: 10

PARTE II: PLAN DE GESTIÓN DE PROYECTO DE PRUEBAS DEL SRA. 13

INFORMACIÓN DEL PROYECTO 13

Definiciones, acrónimos y abreviaturas 16

1.1 DESCRIPCIÓN GENERAL 17

1.1.1 Perspectiva del producto 17

1.1.2 Funcionalidad del producto 18

1.1.3 Modelamiento de Casos de uso de SRA: 18

1.1.4 Características de los usuarios 21

1.1.6 Suposiciones y dependencias 22

1.1.7 Evolución previsible del sistema 22

1.2 REQUISITOS ESPECÍFICOS 22

1.2.1 REQUISITOS COMUNES DE LAS INTERFACES 22

Plan de Pruebas del Sistema de Registro de Asistencia

1.2.1.1 Interfaces de usuario 22

1.2.1.2 Interfaces de hardware 22

1.2.1.3 Interfaces de software 23

1.2.1.4 Interfaces de comunicación 23

1.2.2 REQUISITOS FUNCIONALES 23

1.2.2.1 Ingreso a la aplicación 23

1.2.2.2 Administración de asistencia 24

1.2.2.3 Administración de reporte 24

1.2.3 REQUISITOS NO FUNCIONALES 25

1.2.3.1 Requisitos de rendimiento 25

1.2.4 Otros requisitos 26

2 PLAN DE GESTIÓN DE CALIDAD 26

2.1 ALCANCE DE LAS PRUEBAS 26

2.1.1 Elementos de pruebas 26

2.1.2 Nuevas funcionalidades a probar. 26

2.1.3 Pruebas de regresión 28

2.1.4 Funcionalidades a no probar 29

2.2 PROCEDIMIENTOS PARA LAS PRUEBAS 29

2.2.1 Criterios de aceptación o rechazo 30

2.2.2 Criterios de suspensión 31

2.2.3 Criterios de reanudación 33

2.2.4 Roles del personal: 33

2.2.5 Matriz de responsabilidades: 34

Plan de Pruebas del Sistema de Registro de Asistencia

2.2.8 Dependencias y Riesgos: 37

2.3 RECURSOS Y HERRAMIENTAS DE PRUEBAS 37

2.3.1 Requerimientos de Entornos – Hardware 37

2.3.2 Requerimientos de Entornos – Software 37

2.3.3 Herramientas de Pruebas Requeridas 38

PARTE III: DESARROLLO CON HERRAMIENTA DE MEDICIÓN 40

1 PLAN DE PRUEBAS DE SOFTWARE: 40

1.1 Enfoque de pruebas 40

2 HERRAMIENTA DE CALIDAD DEL PRODUCTO (SonarQube) 41

2.1 Instalación y descripción de uso del SonarQube: 41