PORCENTAJE DE
CUMPLIMIENTO DE
N.º ELEMENTO NOMBRE DE LA MÉTRICA LA
CARACTERÍSTICA
DE CALIDAD
1 Calidad Planeación del día de la entrevista con
el cliente 100%
2 Calidad Evaluación de las necesidades del
proyecto 100%
3 Desempeño Desarrollo de la documentación
iterativa e incremental 100%
Evaluación de la estimación los costos
4 Calidad
del proyecto 100%
5 Calidad Distribución de tareas 80%
6 Calidad Capacidad de escalabilidad 75%
Verificación del seguimiento del diseño
7 Desempeño
respecto al maquetado 50%
Desarrollo de un diseño responsive y
8 Calidad
adaptable a cualquier dispositivo 80%
9 Calidad Cumplir con los requerimientos del
proyecto 80%
Desarrollo de la codificación del
10 Calidad
proyecto en plazos establecidos 75%
Desarrollo de las pruebas funcionales y
11 Calidad
no funcionales 15%
12 Calidad Cobertura de pruebas 10%
13 Calidad Tiempos de respuestas en diferentes 80%
dispositivos
Desarrollo de la implementación del
14 Calidad proyecto 0%
15 Calidad Cumplimiento del plazo de elaboración
del proyecto 50%
Evaluación de la documentación final 0%
16 Calidad
del proyecto
17 Calidad Satisfaccion del cliente 50%
18 Desempeño Feedback de los miembros del equipo 0%
sugerencias:
● Cobertura de pruebas
● Satisfaccion del cliente
● Feedback de los miembros del equipo
● Tiempos de respuestas en diferentes dispositivos
● Distribución de tareas
● Capacidad de escalabilidad
PLAN DE GESTIÓN DE CALIDAD
PLAN DE LA GESTIÓN DE LA CALIDAD ID: 2020SED
NOMBRE DEL PROYECTO:
Sistema para Evaluación Docente
DIRECTOR DEL PROYECTO:
Ixchell Salgado Nazario
DESCRIPCIÓN:
El sistema consiste en realizar una evaluación docente, por
medio de una aplicación web, tomando como rubros la
correcta gestión de documentación, en tiempo y forma.
La evaluación docente no incluye los demás rubros que
conforman la evaluación 360, como lo es la evaluación de los
alumnos hacia el profesor y la autoevaluación de los
profesores.
El resultado más relevante de este proyecto es la gestión
documental para docentes (subir documentos) y del rol
coordinador revisar dicha documentación de cada docente
para su correcta evaluación.
JUSTIFICACIÓN:
La Universidad Tecnológica de Acapulco requiere una aplicación
web que ayude a reducir el tiempo para gestionar los
documentos de evaluación.
Actualmente, la universidad no cuenta con una aplicación web
de evaluación para agilizar este problema.
FECHA DE ELABORACIÓN:
03 / 08 / 2023
ESTÁNDARES
Se implementarán estándares y métricas de ISO/IEC 9126 que proporcionan
modelos, normas que permitan establecer nuestro propio modelo de calidad en
función de las características del software que se quiera evaluar.
Asimismo se evaluarán las métricas con diversos organismos internacionales de
calidad como lo es Project Management Institute (PMI).
ROLES Y RESPONSABILIDADES
No. ROL RESPONSABILIDAD ACTIVIDADES QUE SE HERRAMIENTA
ES REALIZARÁN CON
RESPECTO A LA
CALIDAD
1 Líder del Supervisar que se Realizar reuniones Entrevistas con el
proyecto cumplan las continuas y pruebas cliente,
métricas y de software. cuestionarios a los
estándares de usuarios finales.
calidad antes Herramientas de la
mencionados. organización
Normas de 9126
ISO
2 Analista Brindar las mejores Buscar la mejor Implementar
métricas y reglas a metodología y las medidas y
seguir que se mejores herramientas metodologías que
adecuen al de desarrollo que se brinden una mejor
proyecto. adapten al proyecto. ayuda a la calidad
Proporcionando del software.
confiabilidad, Un ejemplo sería
optimidad y OWASP esto
eficiencia. entorno a la
seguridad
informática.
3 Back– Hacer que el Desarrollar módulos Utilización de
end/Front- sistema sea que cumplan con las lenguajes de
End accesible para todo exigencias antes programación,
tipo de personas y mencionadas. entorno de
haciendo que sea desarrollo
sencillo de usar y integrado (IDE),
aprender, de este sistema gestor de
modo, siendo un base de
sistema de fácil datos,servidor
entendimiento. local.
Implementando el
mayor número de
solicitudes del
cliente final.
4 Tester Verificar que cada Realizar pruebas Cuestionarios y
componente de la rigurosas al sistema herramientas de
aplicación funcione como: caja negra, caja software como:
correctamente y blanca y hacking ético ● OctoPerf
cumpla con los ● JMeter
requisitos ● OWASP
establecidos. Zed Attack
Proxy (ZAP)
PROCESOS O PROCEDIMIENTOS
Se realizará una interfaz amigable para el usuario final haciendo que sea intuitivo para
las nuevas y viejas generaciones.
Al contar con una base de datos local, se realizan copias de seguridad para mantener
actualizada la información, así como poder dar mantenimiento a la base de datos para
mejorar constantemente el rendimiento de respuesta.
Al ser una aplicación web, está será fácil de transportar ya que solo necesitará ingresar
a la página para trabajar en ella.
Al ser un sistema local la eficiencia no es un problema pues no es necesaria la conexión
a internet por ende no esperará respuesta de un servidor de Internet.
Con meticuloso análisis se cumplirá con todos o la mayoría de requisitos que el cliente
pida para así satisfacer sus requisitos.
ENTREGABLES
WBS # Entregable Especificacio Método de Verificación Criterio de aceptación Responsable
nes o (para verificar que se (que tiene que cumplir)
requisitos haga)
1.1.1 DeterminacióRealizar Verificación de hechos Se deben llegar a un Líder de Proyecto:
n de entrevistas acuerdo en el cual Ixchell Salgado
requerimient para estipula los Nazario
os determinar los requerimientos del
requerimientos sistema, lo que se
necesarios del realizará y el alcance que
sistema. obtendrá el proyecto
1.1.2 Propuestas Proporcionar Verificación de hechos La propuesta debe ser la Analista y líder del
de solución propuestas de mejor opción para el proyecto: Melani
qué proyecto, así mismo Estefania Salazar
tecnologías se debe ser aceptada por el Gonzalez e Ixchell
podrían utilizar cliente. Salgado Nazario
para realizar
un mejor
resultado.
1.2 Planificación Prueba de consistencia Debe contar con una Analista y líder del
y estimación Realización buena organización del proyecto:Melani
del proyecto de una tiempo, verificando que el Estefania Salazar
agenda o cronograma esté Gonzalez e Ixchell
cronogram debidamente Salgado Nazario
a que especificado
proporcione
una fecha
estimada
del
proyecto.
1.2.1 Plan de Lista de Verificación El documento de plan de Analista y líder del
gestión de Implementa gestión debe de estar proyecto: Melani
los r un especificando todas las Estefania Salazar
requerimient documento actividades del Gonzalez e Ixchell
os. que ayude cronograma, así mismo Salgado Nazario
cómo estas contar con la firma
recibirá, del patrocinador /cliente y
analizará, el líder del proyecto,
documentar aceptando que se
á y realizará todo lo que se
gestionará estipula en este.
todos los
requisitos
dentro de
un
proyecto.
1.2.2.2 Desarrollo Comparación con Debe de estar Analista: Melani
iterativo e Desarrollo Estándares desarrollado cada uno de Estefania Salazar
incremental de la los documentos uno Gonzalez
documenta atrás del otro,
ción comparando cada uno de
necesaria estos y tengan la misma
respecto a sintonía, además de ser
la aceptados por el líder del
proyecto.
metodologí
a
seleccionad
a.
1.2.2.2.1 Diagramas Representa Prototipos y Maquetas Debe tener una buena Analista: Melani
de flujo r de estructura, entendible y Estefania Salazar
manera sobre todo muy bien Gonzalez
visual y especificado, pensando
gráfica la en todas las actividades
secuencia y o casos que puedan
pasos suceder.
estructurad
os
requeridos
para
desarrollar
un proceso
complejo
del
proyecto.
1.2.2.2.2 Diagramas Ayudarán a Análisis de Casos de Uso El diagrama debe de Analista: Melani
de casos de especificar representarse de manera Estefania Salazar
uso la clara, concisa y Gonzalez
comunicaci entendible para que
ón y los pueda ser comprendida
comportami por el cliente
entos entre
el sistema y
el usuario.
1.2.2.2.4 Historias de Simulación y Prueba de Estas deben de coincidir Analista: Melani
usuario Implement Escenarios con el número de Estefania Salazar
ación de iteración, debe ser una Gonzalez
una descripción general de la
explicació actividad que realiza
n general cada usuario, además de
e informal ser aceptada y firmada
de una por el cliente.
función de
software
escrita
desde la
perspectiv
a del
usuario
final o
cliente.
1.2.3 EDT/WBS Realizar Diagramas y Modelos Debe de tener una Analista: Melani
una estructura entendible, Estefania Salazar
estructura que cada fase sea Gonzalez
de comprensible y vaya
desglose acorde a lo que se indica,
del trabajo. este debe ser aprobado
por el líder del proyecto.
1.2.4 Cronograma Implementa Plan de entrega Debe de especificar cada Líder del proyecto:
de ción de una actividad, quién la va a Ixchell Salgado
actividades herramient desarrollar y en cuanto Nazario
a de tiempo se va a llevar a
gestión de cabo y debe estar
proyectos aprobada y firmada por el
que cliente y el líder del
muestra el proyecto.
listado de
tareas
necesarias
para
realizar un
proyecto en
orden
cronológico
.
1.3.1 Front- Prototipos y Maquetas Los bocetos y mockups Programadores de
end:Diseño Se deben cumplir con los Front-end: Sarahí
de Software realizarán requisitos y Santamaria Ruiz y
bocetos, especificaciones Emma Flores
mockups y definidos para el Carmona
diseños de proyecto. Deben reflejar
lo que las funcionalidades,
serán las características y flujo de
ventanas usuario esperados.
del
proyecto,
con la
intención
de que
esos
mismos
diseños se
repliquen y
se realicen
en
codificación
en la
siguiente
etapa.
1.3.2.1 Diseño Prototipos y Maquetas La base de datos debe Programadores de
conceptual y Se cumplir con todos los Back-end: Sarahí
relacional realizará un requisitos funcionales Santamaria Ruiz y
diseño de especificados en los Emma Flores
la base de documentos de Carmona
datos con requerimientos. Por
el fin de ejemplo, debe permitir la
identificar inserción, actualización y
cuáles son consulta de datos de
las manera correcta.
entidades
que
tendrán
datos y así
poder ver
un
panorama
más claro
de cómo se
maneja la
información
. Con el
objetivo de
corregir o
reducir
posibles
fallos de
comunicaci
ón.
1.4.1.1 Realización Prototipos y Maquetas Las vistas deben de Programadores de
de vista de Se apegarse al maquetado Front-end: Sarahí
todas las realizaron original, deben de ser Santamaria Ruiz y
ventanas del todas las responsivas y adaptarse Emma Flores
sistema interfaces a cualquier dispositivo, Carmona
gráficas, deben de tener una
siendo muy interfaz agradable para el
fieles al usuario y estas deberán
ser aprobadas por el líder
diseño de del proyecto y el cliente.
los
prototipos,
utilizando
los
lenguajes
de
programaci
ón y
frameworks
de css.
Codificación Verificación de código Debe cumplir con todos Programadores de
del módulo Codificació fuente los módulos que ya se Back-end
del n del habían establecido, estos
1.4.2.1 coordinador módulo deben de funcionar
coordinador correctamente y sin
, donde ningún error aparente,
estará el que todos los link esten
login, sus bien redireccionados,
submódulo cumpliendo estos deberá
s donde ser revisado y autorizado
podrá por el líder del proyecto.
realizar
todas sus
actividades.
Submódulo Verificación de código El submódulo deberá Programadores de
de Codificació fuente cumplir con el correcto Back-end: Elías
1.4.2.1. asignación n de los funcionamiento al Bautista Chautla y
1 de maestros Submódulo momento de ingresar, Pablo García
s del consultar, eliminar y Melgarejo
docente, editar todos los datos del
asignando docente
materias,
carrera (s)
y grupo(s)
a los
respectivos
maestros.
1.4.2.1. Submódulo Verificación de código El submódulo deberá Programadores de
2 de Codificació fuente cumplir con el correcto Back-end: Elías
asignación n del funcionamiento al Bautista Chautla y
de materias submódulo momento de asignarles Pablo García
en el que el las materias a los Melgarejo
coordinador docentes, deberá tener
asignará datos precargados de los
las maestros, materias,
materias carreras, etc. Para que al
que momento de la
impartirán asignación solo tenga
los que seleccionar de los
docentes. existentes.
Submódulo Verificación de código Toda la documentación Programadores de
de Se fuente relacionada con el Back-end. Elías
1.4.2.1. supervisión realizará la submódulo, como Bautista Chautla y
3 de entrega codificación manuales de usuario y Pablo García
de del documentación técnica, Melgarejo
documentaci apartado debe estar completa y
ón en el cual actualizada.
el
coordinador
podrá
visualizar la
entrega de
la
documenta
ción de los
docentes.
Submódulo Verificación de código El submódulo debe de Programadores de
de creación En estos fuente entregarse sin problemas Back-end: Elías
1.4.2.1. de submódulo con el servidor o de Bautista Chautla y
cuatrimestre s se componentes del sistema Pablo García
4
s, carreras, crearán y no debe causar Melgarejo
nivel. todos los conflictos ni
CRUD de interrupciones.
las
carreras,
niveles que
existen, así
como dar
de alta el
cuatrimestr
e.
1.4.2.2 Codificación Verificación de código El submódulo debe Programadores de
del módulo Codificació fuente cumplir con los requisitos Back-end: Elías
del docente n del de rendimiento Bautista Chautla y
módulo del establecidos, como Pablo García
docente tiempos de respuesta, Melgarejo
donde velocidad de
encontrará procesamiento y
su login, capacidad de manejo de
todos sus usuarios.
submódulo
s y
actividades
que podrá
realizar.
1.4.2.2. Submódulo Verificación de código El submódulo debe Programadores de
1 para Se hará la fuente cumplir con los requisitos Back-end: Elías
importar codificación de rendimiento Bautista Chautla y
documentaci del módulo establecidos, como Pablo García
ón (Actas, donde los tiempos de respuesta, Melgarejo
Secuencias docentes velocidad de
didácticas, podrán procesamiento y
etc.) subir toda capacidad de manejo de
su usuarios.
documenta
ción
respecto al
cuatrimestr
e que se
encuentra.
1.5.1 Pruebas de Pruebas de Ejecución El sistema debe cumplir Tester: Luis Alberto
aceptación Se con todas las Nieto Figueroa.
realizarán funcionalidades
las pruebas especificadas en los
de requisitos.
aceptación
en la cual
nos dará el
resultado
de pruebas
de
integración,
sistema,
humo, etc.
1.5.2 Pruebas no Pruebas de Ejecución Dicho sistema debe de Tester: Luis Alberto
funcionales Se cumplir con varios Nieto Figueroa
realizarán aspectos como el
pruebas no rendimiento,
funcionales disponibilidad, usabilidad
que entre otros.
brindarán
información
acerca del
rendimiento
,
capacidad,
usabilidad y
portabilidad
, se
implementa
rán
herramient
as
tecnológica
s para el
uso de
estas.
1.6.1 Documen Documentación Técnica La documentación debe Líder del proyecto:
tación La estar escrita de manera Ixchell Salgado
final del documenta clara y concisa, evitando Nazario
ción final es ambigüedades y jerga
sistema
el proceso técnica innecesaria.
en el cual Todos los aspectos clave
se del sistema deben estar
entregará cubiertos.
toda la
documenta
ción que se
llevó a
cabo,
detallando
información
relevante
como
futuras
actualizacio
nes o como
darle
mantenimie
nto al
proyecto,
incluso,
algunos
entregables
.
1.6.2 Implement Simulación y Prueba de Se verifica que el Equipo LEMPIS
ación del Es el proceso Escenarios software funcione
software de instalar, correctamente en
configurar, diferentes dispositivos,
una también que el mismo
aplicación, haya cumplido con todos
que está esté los requisitos y
en línea. estándares.
Elaboró el Analista: Autorizo:
Melani Estefania Salazar Gonzalez Mtra. Carolina Gordillo Gomez
Administrador del Proyecto: Patrocinador del Proyecto:
Ixchell Salgado Nazario Mtro. Jesus Alejandro Alvarez Galena
1. **Revisión por Pares:** Se asigna a uno o varios revisores para que examinen la
documentación en busca de errores, omisiones o ambigüedades. Esta revisión colaborativa
garantiza una mayor precisión.
2. **Verificación de Hechos:** Se verifica que la información proporcionada en la
documentación sea precisa y esté respaldada por pruebas o referencias confiables.
3. **Auditoría de Documentación:** Se realiza una revisión exhaustiva de la documentación
para asegurarse de que cumpla con las normas y estándares establecidos para la
organización.
4. **Pruebas de Ejecución:** Si la documentación incluye instrucciones para utilizar el
software, se pueden seguir las instrucciones y verificar si el software se comporta de
acuerdo a lo descrito.
5. **Pruebas de Comprensión:** Se pide a un grupo de usuarios o miembros del equipo que
sigan las instrucciones proporcionadas en la documentación y luego se les hace preguntas
para evaluar su comprensión.
6. **Pruebas de Ejemplos:** Se incluyen ejemplos en la documentación y se verifica si son
correctos y fáciles de seguir.
7. **Comparación con el Código:** Se compara la documentación con el código fuente del
software para asegurarse de que la descripción se ajuste a la funcionalidad real.
8. **Revisiones de Estilo y Formato:** Se verifica que la documentación siga una estructura
coherente, use un lenguaje claro y tenga un formato fácil de leer.
9. **Pruebas de Coherencia:** Se verifica que la documentación sea coherente en términos
de terminología y enfoque a lo largo de todo el documento.
10. **Pruebas de Actualización:** Se asegura de que la documentación esté actualizada y
refleje los cambios más recientes en el software.
11. **Pruebas de Enlace y Referencias:** Se verifican los enlaces a recursos externos y las
referencias cruzadas dentro del documento para asegurarse de que sean correctos y
funcionales.
12. **Pruebas de Usabilidad de la Documentación:** Se evalúa si la documentación es fácil
de navegar y si los usuarios pueden encontrar rápidamente la información que necesitan.
13. **Entrevistas o Encuestas a Usuarios:** Se consulta a los usuarios sobre la utilidad y
claridad de la documentación para identificar áreas de mejora.
14. **Pruebas de Traducción (si aplica):** Si la documentación se traduce a diferentes
idiomas, se verifica que las traducciones sean precisas y comprensibles.
1. Documentación Técnica: Incluir manuales de usuario, manuales técnicos, documentación
de diseño, descripción de la arquitectura, entre otros.
2. Código Fuente: Especificar que se entregará el código fuente completo y organizado del
software desarrollado.
3. Prototipos y Versiones Alfa/Beta: Si se sigue un enfoque de desarrollo iterativo, se
pueden incluir prototipos y versiones preliminares del software para revisión y validación por
parte de los stakeholders.
4. Casos de Prueba y Planes de Prueba: Entregar los casos de prueba diseñados, así como
los planes de prueba para verificar y validar el software.
5. Informe de Pruebas: Incluir un informe detallado sobre los resultados de las pruebas
realizadas, incluyendo los errores encontrados y su resolución.
6. Interfaz de Usuario: Si el proyecto incluye una interfaz gráfica, se deben proporcionar las
pantallas y elementos de la interfaz.
7. Datos de Ejemplo: Si es necesario, se pueden proporcionar datos de ejemplo para
demostrar el funcionamiento del software.
8. Diagramas y Modelos: Incluir diagramas de flujo, diagramas de clases, diagramas de
secuencia u otros modelos que representen la estructura y el funcionamiento del software.
9. Manual de Instalación: Si el software es instalable, proporcionar instrucciones detalladas
sobre cómo instalarlo en diferentes entornos.
10. Informe de Cumplimiento de Requisitos: Un informe que detalle cómo los entregables
cumplen con los requisitos previamente definidos.
11. Informes de Rendimiento y Estabilidad: Si se han realizado pruebas de rendimiento y
estabilidad, incluir informes con los resultados.
12. Entregables de Proceso: Puede incluir entregables relacionados con el proceso de
desarrollo, como revisiones de código, informes de seguimiento y reportes de avance.
13. Capacitación y Soporte: Si se ofrecen servicios de capacitación y soporte, incluir
detalles sobre los materiales de capacitación y el nivel de soporte brindado.
14. Entregables de Diseño y Arquitectura: Si el software implica un diseño y arquitectura
complejos, se pueden incluir diagramas detallados y especificaciones técnicas.
15. Plan de Entrega: Un cronograma detallado que indique cuándo se entregarán los
distintos entregables a lo largo del proyecto.
1. Revisión por Pares (Peer Review):
- Ejemplo 1: Dos miembros del equipo revisan conjuntamente un manual de usuario para
identificar errores gramaticales y conceptuales.
- Ejemplo 2: Un desarrollador revisa el código fuente de otro desarrollador para
asegurarse de que siga las convenciones de codificación.
2. Revisión de Expertos (Expert Review):
- Ejemplo 1: Un experto en seguridad revisa el diseño de seguridad de una aplicación para
identificar posibles vulnerabilidades.
- Ejemplo 2: Un experto en usabilidad revisa la documentación de diseño de la interfaz de
usuario para evaluar su facilidad de uso.
3. Lista de Verificación (Checklist):
- Ejemplo 1: Se utiliza una lista de verificación para asegurarse de que todos los
elementos requeridos estén presentes en un manual de instalación.
- Ejemplo 2: Una lista de verificación se utiliza para confirmar que todas las secciones
obligatorias están incluidas en un informe de prueba.
4. Comparación con Estándares (Standards Comparison):
- Ejemplo 1: La documentación se compara con las normas de documentación definidas
para asegurarse de que cumple con los formatos y convenciones requeridos.
- Ejemplo 2: Se verifica si los requisitos en la documentación cumplen con los estándares
y regulaciones de la industria.
5. Simulación y Prueba de Escenarios (Scenario Simulation and Testing):
- Ejemplo 1: Se simulan diferentes escenarios de usuario para probar la documentación
de un manual de usuario y verificar si las instrucciones son claras.
- Ejemplo 2: Se realizan pruebas de ejecución de los ejemplos de código en la
documentación técnica para asegurarse de que funcionan correctamente.
6. Auditoría Documental (Documentary Audit):
- Ejemplo 1: Un auditor verifica si la documentación de los requisitos refleja con precisión
las necesidades del cliente.
- Ejemplo 2: Se lleva a cabo una auditoría para verificar si la documentación cumple con
las regulaciones de seguridad requeridas.
7. Verificación de Vocabulario y Términos (Vocabulary and Terminology Verification):
- Ejemplo 1: Se verifica que los términos técnicos utilizados en la documentación estén
definidos y utilizados correctamente.
- Ejemplo 2: Se revisa la coherencia de la terminología en la documentación para evitar
ambigüedades.
8. Prueba de Consistencia (Consistency Testing):
- Ejemplo 1: Se verifica que las fechas y números en diferentes partes de la
documentación sean coherentes entre sí.
- Ejemplo 2: Se revisa que las referencias cruzadas entre secciones y páginas sean
precisas y consistentes.
9. Revisión de Formato y Diseño (Format and Design Review):
- Ejemplo 1: Se verifica que el formato de la documentación siga un diseño uniforme en
cuanto a fuentes, tamaños y estilos.
- Ejemplo 2: Se revisa la disposición de los elementos gráficos y tablas en la
documentación para asegurarse de que sean legibles.
10. Verificación de Cumplimiento Normativo (Regulatory Compliance Verification):
- Ejemplo 1: Se verifica que la documentación cumple con los estándares de privacidad y
protección de datos exigidos por las leyes locales.
- Ejemplo 2: Se confirma que la documentación cumple con los requisitos de accesibilidad
para personas con discapacidades, según los estándares de la industria.
