G5 - Plan de Aseguramiento de Calidad - InformeFinal

Plan de aseguramiento de la calidad
Índice
Índice 1
A. Planificación 3
a. Objetivo 3
b. Entrada 3
c. Proceso 4
d. Salida 5
e. Lista de Verificación (Checklist) 6
f. Métricas 7
g. Involucrados 8
B. Requerimientos 9
a. Objetivos 9
b. Entradas 9
c. Proceso 9
d. Salida 11
f. Métricas 12
g. Involucrados 13
C. Análisis 13
a. Objetivo 13
b. Entradas 14
c. Salidas 15
d. Lista de Verificación (Checklist) 15
e. Métricas 16
f. Involucrados 17
D. Diseño 19
1. Objetivo 19
2. Entradas 19
3. Proceso 21
4. Salidas 22
5. Checklist 23
6. Métricas 25
7. Involucrados 26
E. Codificación 26
a. Objetivo 26
b. Entradas 26
c. Proceso 28
d. Salidas 30
e. Checklist 30
f. Métricas 32
g. Involucrados 33
F. Pruebas 33
a. Objetivo 33
Barazorda P., Espinoza S., Mirano F., Ore G., Quispe J., Sanchez J. 1
b. Entradas 34
c. Proceso 34
d. Salidas 35
f. Métricas 37
g. Involucrados 38
G. Instalación 39
a. Objetivo 39
b. Entradas 39
c. Proceso 40
d. Salidas 42
f. Métricas 44
g. Involucrados 44
Plan de Aseguramiento de Calidad
A. Planificación
a. Objetivo
El objetivo de la fase de Planificación es establecer las bases y los
lineamientos para llevar a cabo el proyecto de desarrollo de software de
manera efectiva y eficiente. Esto implica determinar con precisión qué
recursos serán necesarios y estarán disponibles para llevar a cabo el proyecto
de software asociado. Al hacerlo, se busca prever y mitigar posibles
obstáculos o retrasos que puedan surgir durante el desarrollo.
En esta etapa, se busca responder a preguntas críticas como:
● ¿Qué recursos humanos serán requeridos y en qué roles?
● ¿Cuánto tiempo se estima que tomará completar cada fase del
proyecto?
● ¿Cuáles son los costos asociados con el proyecto?
● ¿Qué herramientas o tecnologías se necesitarán para llevar a cabo el
desarrollo?
En resumen, el objetivo es proporcionar una hoja de ruta clara y detallada para
el proyecto de desarrollo de software, lo que permite a los equipos trabajar de
manera coordinada y eficaz hacia la consecución de los objetivos del proyecto.
b. Entrada
1. Estimación del proyecto y método utilizado para realizarla:
La estimación del proyecto es una evaluación sistemática y anticipada
de los recursos necesarios para llevar a cabo el proyecto de desarrollo
de software. Esto incluye factores como el tiempo, los recursos
humanos, la infraestructura tecnológica y los costos asociados.
El método utilizado para realizar esta estimación puede variar según
las prácticas y las herramientas disponibles. Puede incluir enfoques
basados en la experiencia pasada, análisis de similares proyectos
previos, técnicas de descomposición y estimaciones paramétricas
utilizando herramientas especializadas.
2. Plan de desarrollo (de software) del proyecto y descripción del
proceso de desarrollo:
El plan de desarrollo es un documento integral que delineará cómo se
llevará a cabo el proyecto de desarrollo de software. Incluye una
secuencia de actividades, roles y responsabilidades, así como los
entregables esperados en cada etapa.
La descripción del proceso de desarrollo a utilizar en el proyecto es
una especificación detallada de la metodología o enfoque que se
seguirá durante el desarrollo del software. Puede ser ágil, en cascada,
en espiral u otros modelos. Proporciona pautas sobre cómo se realizará
el trabajo, cómo se gestionarán los cambios y cómo se llevará a cabo la
integración y las pruebas.
c. Proceso
i. Verificación de la Estimación del Proyecto
La verificación de la estimación del proyecto constituye un proceso
esencial que se desarrolla con el propósito de analizar y autenticar la
exactitud de las estimaciones realizadas previamente en la fase de
planificación del proyecto. Este procedimiento tiene como finalidad
asegurar que las estimaciones sean coherentes con las condiciones y
requisitos actuales del proyecto, con el fin de que sean verdaderamente
viables y reflejan la realidad.
En la hipótesis de que se detecten desviaciones sustanciales entre las
estimaciones originales y la situación presente del proyecto, se
establece la posibilidad de realizar modificaciones y ajustes en el plan
del proyecto. Estos ajustes pueden abarcar aspectos relacionados con la
asignación de recursos, plazos y presupuesto, con el propósito de
asegurar que el proyecto siga siendo realista y acorde con las
circunstancias cambiantes.
ii. Verificación del Estado del Proyecto
La verificación del estado del proyecto es una especie de control para
comprobar si el proyecto está avanzando como se esperaba. Significa
observar si se están cumpliendo los hitos y si se están usando los
recursos según lo planeado. Si notamos problemas importantes o cosas
que no van como se había previsto, tomamos medidas para corregir el
rumbo y asegurarnos de que el proyecto siga en la dirección correcta.
Esta etapa nos ayuda a mantener el proyecto en el camino correcto y a
solucionar cualquier problema que surja en el camino.
d. Salida
La conclusión de la etapa de planificación y verificación del proyecto implica
la generación de diversos documentos y datos relevantes. Estos incluyen
informes de progreso que detallan el estado actual del proyecto,
actualizaciones en la documentación del plan del proyecto, métricas que
ofrecen una visión cuantitativa de la calidad y el desempeño del software, y
cualquier otra información o entregable pertinente. Estos elementos resultan
cruciales para mantener a todas las partes interesadas informadas sobre el
progreso del proyecto y para garantizar que se cumplan los objetivos
establecidos.
e. Lista de Verificación (Checklist)
Una lista de verificación o checklist es una herramienta que enumera una serie
de tareas, actividades o elementos críticos que deben completarse antes,
durante o después de un proyecto. Su objetivo es asegurarse de que no se
omita ningún paso importante en la planificación y ejecución del proyecto. La
lista de verificación ayuda a los gerentes de proyecto a mantenerse
organizados, a seguir un proceso estandarizado y a garantizar que se cumplan
todos los requisitos y entregables del proyecto en el momento adecuado.
ÍTEM CUMPLE DESCRIPCIÓN

Nosotros para poder desarrollar el
software en San Marcos sí
¿El equipo del proyecto tiene
tenemos un plan de proyecto
conocimiento del proceso de
anual, haciendo una proyección de
desarrollo utilizado para Sí
todos los
construir el software
desarrollos,mantenimientos,
especificado por el proyecto?
mejoras que se vayan a hacer
durante el año
El plan de proyecto contempla
costo, equipo, actividades a
desarrollar, puntos de control a
¿El plan de proyecto está
Sí ejecutar. A su vez el plan de
completo?
proyecto no contempla el plan de
comunicaciones, ya que es parte
de la metodología
¿La estimación del proyecto La estimación es anual, donde se

está totalmente Sí documentan los sistemas que se
documentada? van a mantener o lanzar
Se ha desarrollado una
metodología tradicional en la
¿El proceso de desarrollo mayor parte de proyectos donde se
está totalmente Sí da una documentación detallada.
documentado? Quiere decir que se tienen
documentos de análisis, diseño,
desarrollo y pruebas.
La estimación está relacionada al
¿El método de estimación tiempo, en base a esto se puede
utilizado para el proyecto, es conocer el costo. El tiempo es
Sí
razonable respecto de las evaluado por los líderes de
características del mismo? desarrollo, análisis, arquitecto de
software y DBA.
El plan es a futuro, por lo tanto no
¿La estimación efectuada es
siempre es exacta; a veces se
razonable como para
Sí presentan incidentes lo que
completar el proyecto según
conlleva a un incumplimiento del
lo especificado en el plan?
cronograma.
Existe un solo entregable que se
¿El equipo del proyecto tiene
remite de forma mensual, donde
un método definido para
Sí se detalla el conjunto de
determinar e informar el
actividades que hizo cada uno de
estado del mismo?
los integrantes del proyecto
f. Métricas
Las métricas son medidas cuantitativas que se utilizan para evaluar la calidad
y el rendimiento del software. Estas métricas pueden incluir datos sobre la
cantidad de defectos encontrados, la cobertura de las pruebas, el tiempo
promedio de corrección de errores y otros indicadores relevantes para la
calidad del software. Al establecer métricas claras al comienzo del proyecto,
se proporciona un marco objetivo para evaluar la calidad del software y medir
su mejora a lo largo del desarrollo.
1. Índice de Cumplimiento de Plazos (On-Time Delivery Rate):
El "Índice de Cumplimiento de Plazos" (On-Time Delivery Rate) es una
métrica que se utiliza para evaluar la puntualidad en la entrega de tareas,
funcionalidades o proyectos dentro de un contexto de desarrollo de software o
gestión de proyectos en general. Esta métrica mide la proporción de entregas
que se realizaron dentro de los plazos planificados en comparación con el total
de entregas programadas. Puede aplicarse en entornos tanto tradicionales
como ágiles para evaluar la capacidad de cumplir con los plazos de entrega.
2. Error de estimación
El "Error de Estimación" es una métrica que se utiliza para evaluar la precisión
de las estimaciones realizadas en un proyecto. Representa la diferencia entre la
estimación original (la cantidad de tiempo, esfuerzo, o recursos que se
esperaba que se necesitaran) y el valor real (la cantidad real de tiempo,
esfuerzo o recursos que se necesitaron) para completar una tarea o actividad en
el proyecto. El Error de Estimación se utiliza para medir cuán cerca o lejos
estuvo la estimación original de la realidad.
g. Involucrados
i. Equipo de Ingeniería
El equipo de ingeniería en el desarrollo de software está compuesto por
profesionales especializados en la creación y mantenimiento del
software. Esto incluye programadores, desarrolladores, arquitectos de
software, ingenieros de software y otros roles técnicos. Su función
principal es diseñar, codificar y probar el software para garantizar que
cumple con los requisitos del proyecto y que es funcional, eficiente y
confiable.
ii. Equipo de Aseguramiento de la Calidad del Software
Se encarga de garantizar que el software cumple con los estándares de
calidad establecidos y que funciona correctamente. Este equipo realiza
pruebas exhaustivas para identificar y corregir defectos o problemas en
el software antes de su lanzamiento. También colabora estrechamente
con el equipo de desarrollo para mejorar la calidad del software y
garantizar que cumple con las expectativas del cliente o usuario final.
Los miembros del equipo de QA pueden incluir probadores de
software, analistas de calidad, ingenieros de pruebas y otros
profesionales especializados en la garantía de calidad del software.
B. Requerimientos
a. Objetivos
Establecer metas claras y específicas para la recopilación y documentación de
los requisitos del proyecto. Garantizar que los requisitos sean comprensibles,
consistentes y alcanzables para todas las partes interesadas.
b. Entradas
Una entrada se refiere a la información, documentos y elementos que se
utilizan como base para planificar y ejecutar actividades de aseguramiento de
calidad relacionados con los requerimientos del proyecto o producto. Las
entradas proporcionan la información necesaria para comprender y definir
cómo se evaluará y se asegurará la calidad de los requerimientos.
c. Proceso
i. Realizar un Análisis de Factores a Verificar
Esta actividad implica identificar y analizar los factores críticos que se
deben verificar en los requerimientos del proyecto. Los factores a
verificar pueden incluir aspectos como la completitud, la consistencia,
la claridad, la trazabilidad y el cumplimiento con los estándares y
regulaciones aplicables.
Durantes esta fase, el equipo de aseguramiento de calidad debe:
● Identificar los criterios de calidad específicos que se aplicarán a
los requerimientos.
● Definir los factores clave que deben evaluarse en los
requerimientos.
● Establecer métricas y medidas para evaluar estos factores.
● Planificar cómo se llevará a cabo la verificación de estos
factores a lo largo del ciclo de vida del proyecto.
● El resultado de esta actividad es una comprensión clara de qué
factores son esenciales para garantizar la calidad de los
requerimientos y cómo se verificarán.
ii. Conducir un “Walkthrough” de Requerimientos
El “Walkthrough” de requerimientos es una revisión formal y
estructurada de los requerimientos con la participación de las partes
interesadas, incluyendo a los equipos de desarrollo, los usuarios finales
y otros interesados clave. Durante el “walkthrough” se revisan y
discuten los requerimientos para identificar posibles problemas,
ambigüedades, inconsistencias o desafíos de implementación. Esta
actividad tiene como objetivo asegurarse de que los requerimientos
están bien entendidos y sean factibles de implementar. Durante un
"walkthrough" de requerimientos, se pueden discutir preguntas,
aclaraciones y sugerencias, y se pueden tomar decisiones sobre
posibles cambios o mejoras en los requerimientos. Las partes
interesadas aportan sus conocimientos y experiencias para mejorar la
calidad y la comprensión de los requerimientos.
El "walkthrough" es una técnica efectiva para la identificación
temprana de problemas y riesgos relacionados con los requerimientos y
garantizar que sean claros y apropiados.
d. Salida
Una salida en el apartado de requerimientos en un plan de Aseguramiento de
Calidad se refiere a los resultados o productos finales generados como parte
del procesos de aseguramiento de calidad en relación con los requerimientos
del proyecto o producto. Estas salidas son documentos, informes o registros
que muestran cómo se gestionaron, verificaron y validaron los requerimientos
para garantizar su calidad y cumplimiento.
¿Los requerimientos definidos Sí Para que los requerimientos sean

son verificables? verificables deben ser susceptibles
de poder ser atendidos, programados

a nivel de software como a nivel de
procesos. En el caso de San Marcos
es importante estandarizar el
proceso, debido a que cada facultad
tiene sus propias necesidades o
formas de hacer las cosas
¿El usuario está de acuerdo con Sí Se debe establecer actas de

el requerimiento definido? conformidad para establecer los
requerimientos
¿Los desarrolladores entienden Sí La documentación es muy

los requerimientos? importante, se debe hacer un buen
relevamiento de los requerimientos.
¿El requerimiento definido Sí Se debe hacer una trazabilidad y

coincide con los objetivos del verificación.
proyecto?
¿Se identificaron los riesgos del No Para el caso de San Marcos no se

proyecto? está haciendo una identificación
detallada de los riesgos del proyecto
¿Se siguió un proceso razonable Sí Convocatoria, reuniones y la

en la definición del emisión de documentos con los
requerimiento? requerimientos maduros.
¿El proceso de control de No No se está haciendo un “match” para

requerimientos, es adecuado minimizar los riesgos del proyecto
para minimizar los riesgos del
proyecto?
¿Durante el proceso de control Sí Se pacta una reunión para comunicar

de requerimientos se ha llevado a a los clientes los requerimientos
cabo un “walktrough”? acordados.
¿La técnica más adecuada para No Depende de la organización en San

el relevamiento de requisitos es Marcos, las reuniones con clientes
la entrevista? son esenciales para comprender los
flujos del proyecto y encontrar
soluciones óptimas en colaboración
con el equipo
¿Se crea un documento de Sí La documentación y la obtención de

trazabilidad entre el documento conformidades del cliente son
de requisitos y el documento que esenciales para evitar cambios que
los solicita? puedan afectar el alcance, costo y
tiempo del proyecto, alineando los
cambios con la definición inicial del
proyecto
f. Métricas
Las métricas son fundamentales para establecer estándares de calidad y
evaluar el progreso del proyecto. También ayudan a identificar áreas de mejora
en el proceso de definición de requerimientos. El seguimiento constante de
estas métricas durante el desarrollo del proyecto puede contribuir a la entrega
de un sistema de gestión de donantes de sangre que cumple con las
expectativas y necesidades de los usuarios de manera eficiente y efectiva.
Complejidad de los Requerimientos (CR):
Esta métrica evalúa la complejidad de los requerimientos del software. Puede
medirse utilizando diversas técnicas como el conteo de palabras clave, la
identificación de dependencias entre requerimientos, la profundidad de la
jerarquía de los requerimientos, entre otros. Una mayor complejidad puede
indicar potenciales dificultades en el desarrollo y la implementación, lo que
podría resultar en un mayor riesgo de errores y retrasos en el proyecto.
Cobertura de Requerimientos (CR):
Esta métrica evalúa la extensión en la que los requerimientos identificados
abarcan todas las necesidades y expectativas del cliente. Se puede medir
mediante el porcentaje de requerimientos cubiertos en comparación con el
total de requerimientos definidos en el proceso de captura y análisis. Una baja
cobertura de requerimientos puede llevar a una falta de funcionalidades clave
en el producto final, lo que afectaría la satisfacción del cliente y la calidad
general del software.
g. Involucrados
i. Equipo de Ingeniería:
Responsable de comprender los requisitos técnicos y garantizar su
implementación adecuada.
ii. Equipo de Aseguramiento de la Calidad de Software:
Encargado de verificar si los requisitos se implementan correctamente
y de garantizar la calidad del producto final en función de los
requisitos establecidos.
C. Análisis
a. Objetivo
El objetivo del análisis del Plan de Aseguramiento de Calidad es evaluar la
efectividad y adecuación del plan para garantizar la calidad en un proyecto,
producto o proceso. Se busca asegurar que cumple con los estándares
requeridos, identificar posibles riesgos y definir roles y responsabilidades
clave.
El análisis proporciona una evaluación integral del Plan de Aseguramiento de
Calidad y asegura que esté preparado para cumplir con los requisitos de
calidad y las expectativas del proyecto o industria en cuestión.
b. Entradas
Se refiere a la información y documentos específicos que se utilizan como
insumos o fuentes de referencia al evaluar o revisar el plan. En un informe de
análisis de una Plan de Aseguramiento de Calidad, este apartado detalla los
documentos, datos y elementos que se toman en cuenta al realizar la
evaluación del plan. Las “entradas” proporcionan contexto y base para el
análisis, permitiendo a los revisores comprender mejor el plan y entorno.
i. Analizar la Especificación Funcional
Se refiere a la evaluación de la documentación que describe las funciones y
características específicas que se esperan de un producto o sistema. Esta
especificación funcional es un componente clave para garantizar que el
producto o sistema cumpla con los requisitos y expectativas de los
stakeholders. El objetivo de este análisis es verificar que el Plan de
Aseguramiento de Calidad esté alineado con estas especificaciones y garantice
la calidad de las funciones y características mencionadas.
ii. Conducir una Inspección Formal
Se refiere a un proceso específico de revisión y verificación de la
documentación y actividades relacionadas con la calidad. Esta actividad se
lleva a cabo de manera formal y sistemática para identificar posibles
desviaciones con respecto a los estándares y requisitos de calidad establecidos
en el plan. Esto implica verificar que el plan establezca claramente:
- Los criterios de inspección y las normas a las que se deben adherir las
actividades de aseguramiento de calidad.
- Los procedimientos y procesos a seguir durante las inspecciones formales.
- Las responsabilidades de las partes involucradas en las inspecciones, así
como el personal designado para llevarlas a cabo.
- Los registros y documentación que se generan como resultado de las
inspecciones formales.
c. Salidas
Se refiere a los resultados y conclusiones que se obtienen después de llevar a
cabo la evaluación y revisión del plan. Estas "salidas" son los productos o
informes que se generan como resultado del análisis y que proporcionan
información importante para la toma de decisiones y acciones posteriores. Las
salidas incluyen: Informe de Análisis, Recomendaciones de Mejora, Resumen
de Riesgos, Validación de la Adecuación del Plan, Registro de Conclusiones y
Planes de Acción.
d. Lista de Verificación (Checklist)
¿La metodología más eficiente o útil No No existe una metodología

para desarrollar proyectos es ágil? universal para todos los
proyectos, se debe adaptar
según las circunstancias y
necesidades del proyecto. A
veces, es necesario combinar
metodologías. Las pruebas se
ajustan a la metodología y al
contexto del desarrollo
¿El usuario final ha estado Sí La participación del usuario es

involucrado en el análisis? esencial desde la propuesta de
solución hasta la construcción
del producto. No se deben
asumir sus necesidades y se
debe estar abierto a escuchar y
ajustar los módulos según sus
requerimientos reales
¿Se considera algún aspecto de Sí En proyectos, es común que

análisis al abordar requerimientos antes de agregar nuevas
que implican una migración funcionalidades o realizar
tecnológica en el proyecto? migraciones, se requiera una
mejora previa en el sistema
existente. La consideración
clave es cómo se llevará a cabo
esta migración, lo que implica

estimar el trabajo tanto en la
mejora existente como en las
nuevas funciones a desarrollar
e. Métricas
i. Acoplamiento
● Mide la interconexión entre módulos o componentes del
software.
● Un bajo acoplamiento indica que los componentes son
independientes y se comunican mínimamente.
● El bajo acoplamiento es deseable para facilitar el
mantenimiento y la flexibilidad del sistema.
ii. Cohesión
● Mide la agrupación de funcionalidades relacionadas en un
mismo módulo o componente.
● Un alto grado de cohesión significa que un componente realiza
una tarea específica y bien definida.
● El alto grado de cohesión es deseable para facilitar la
comprensión y el mantenimiento del sistema.
f. Involucrados
Se refiere a la identificación de las personas y roles específicos que
están relacionados con la gestión de calidad en un proyecto o proceso.
En la parte relacionada con el "Equipo de Ingeniería", se busca
especificar quiénes son los profesionales de ingeniería o ingenieros
involucrados en la implementación y supervisión del Plan de
Aseguramiento de Calidad. Algunos de los roles típicos incluyen:
1. Ingeniero de Calidad: Este profesional se encarga de supervisar y
garantizar que se sigan los procesos y estándares de calidad adecuados
en todas las etapas del proyecto. Puede estar involucrado en la
planificación y ejecución de pruebas y auditorías de calidad.
2. Ingenieros de Diseño: Estos ingenieros son responsables de
garantizar que el diseño del producto o sistema cumpla con las
especificaciones técnicas y de ingeniería, y que sea adecuado para
cumplir con los objetivos de calidad.
3. Gerente de Proyectos: Este equipo se dedica a la planificación y
ejecución de pruebas de calidad para verificar que el producto cumple
con las especificaciones técnicas y de rendimiento. También pueden
estar involucrados en la identificación y corrección de defectos.
4. Grupo de Análisis de Requerimientos: Estos ingenieros se enfocan
en asegurar que los procesos de fabricación o desarrollo sean eficientes
y cumplan con los estándares de calidad. Pueden participar en la
identificación de mejoras en los procesos.
5. Grupo de Análisis Funcional: Estos profesionales se centran en
verificar y validar que el producto o sistema cumpla con los requisitos
establecidos. Esto puede implicar pruebas de validación, verificación
de diseño y otros procesos de aseguramiento de calidad.
6. Responsable de Documentación Técnica: Asegura que la
documentación técnica esté actualizada y que refleje con precisión los
requisitos de calidad y diseño del proyecto.
Se refiere a la identificación de los profesionales y roles específicos
que están relacionados con la gestión de calidad en el desarrollo de
software. Este equipo desempeña un papel fundamental en garantizar
que el software cumpla con los estándares de calidad y funcione de
acuerdo con los requisitos especificados. Algunos de los roles típicos
que podrían estar involucrados en el Equipo de Aseguramiento de la
Calidad del Software incluyen:
1. Líder de Aseguramiento de la Calidad del Software: Es responsable
de la supervisión general de todas las actividades relacionadas con el
aseguramiento de calidad del software.
2. Analista de Aseguramiento de la Calidad de Software: Desempeña
un papel fundamental en garantizar que el software cumpla con los
estándares de calidad y funcione de manera efectiva.
4. Analista de Requisitos de Software: Se aseguran de que los
requisitos del software sean claros, verificables y cumplibles. Ayudan a
establecer una base sólida para el desarrollo de software de alta
calidad.
5. Especialista en Automatización de Pruebas: En algunos proyectos,
este rol se encarga de desarrollar scripts de pruebas automatizadas para
agilizar y mejorar la eficiencia de las pruebas de software.
D. Diseño
1. Objetivo
La fase de Diseño tiene como objetivo establecer los factores que conducen a
un diseño correcto y preciso. Esto implica la identificación y consideración de
elementos clave que garanticen la coherencia del diseño con los
requerimientos establecidos y la metodología definida. Además, se busca
llevar a cabo revisiones e inspecciones de los entregables del diseño para
asegurar su calidad.
2. Entradas
● Especificaciones del diseño: constituyen un documento detallado que
especifica los requisitos específicos del diseño, proporcionando una base
esencial para el proceso de diseño. Este documento actúa como una guía
detallada que orienta a los diseñadores, asegurando la alineación precisa de las
soluciones con los requisitos establecidos, lo que garantiza la satisfacción de
las expectativas del cliente o usuario final.
● Diagramas de flujo del sistema: ofrecen representaciones gráficas que
ilustran la secuencia y la interacción de los componentes del sistema. Su
propósito es facilitar la comprensión visual del sistema, ayudando en la toma
de decisiones durante el diseño. Al proporcionar una vista clara de cómo los
diferentes elementos del sistema se conectan y operan conjuntamente, estos
diagramas permiten una planificación y diseño más efectivos.
● Requerimientos de software y hardware: consisten en especificaciones
detalladas que el diseño debe cumplir, tanto a nivel de software como de
hardware. Su función principal es definir claramente las condiciones y
características que el diseño debe incorporar. Estos requisitos actúan como
puntos de referencia cruciales, asegurando que el diseño sea compatible con
las necesidades y expectativas del usuario, así como con las capacidades
tecnológicas disponibles.
● Documento de diseño de alto nivel (Lógico): proporciona una visión general
lógica del diseño, resaltando los elementos clave y su interconexión. Su
propósito es ofrecer una guía conceptual para el diseño, permitiendo a los
miembros del equipo comprender la estructura y la lógica general del sistema.
Facilita la comunicación entre los diversos stakeholders al presentar una visión
simplificada pero informativa del diseño.
● Documento de diseño de detalle (Físico y lógico): ofrece una descripción
detallada tanto de los aspectos físicos como lógicos del diseño. Este
documento actúa como una guía exhaustiva para la implementación del
diseño, proporcionando información detallada sobre cómo se deben construir y
organizar los componentes físicos y lógicos del sistema. Es esencial para
garantizar una implementación coherente y precisa del diseño.
3. Proceso
● Análisis de Factores
○ Controles de integridad de datos: Se verifica la implementación de
controles para garantizar la precisión y coherencia de los datos en el
diseño.
○ Controles de integridad de archivos: Se asegura la integridad y
consistencia de los archivos utilizados en el diseño, evitando posibles
corrupciones.
○ Método para alcanzar el nivel de servicio requerido: Se define y
evalúa el enfoque utilizado para alcanzar el nivel de servicio necesario
en el diseño.
○ Diseño acorde con la metodología establecida: Se verifica que el
diseño siga la metodología definida, garantizando consistencia en la
implementación.
○ Diseño acorde con los requerimientos establecidos: Se evalúa la
conformidad del diseño con los requisitos específicos del proyecto.
○ Mantenibilidad del diseño: Se analiza la facilidad con la que el
diseño puede ser mantenido y modificado a lo largo del tiempo.
○ Interfaces de diseño: Se examinan las interfaces del diseño para
asegurar la correcta interacción entre los componentes.
○ Diseño acorde con criterios establecidos: Se verifica que el diseño
cumpla con los estándares y criterios predefinidos para asegurar su
calidad.
● Conducción de la Revisión del Diseño
○ Asignar tiempos adecuados: Se asigna el tiempo necesario para llevar
a cabo una revisión exhaustiva, asegurando una evaluación detallada.
○ Documentar los datos de la revisión: Se registran de manera
detallada los hallazgos y comentarios durante el proceso de revisión.
○ Revisar los datos con el equipo de proyecto: Se lleva a cabo una
revisión conjunta de los datos con el equipo de proyecto para obtener
diferentes perspectivas y asegurar una evaluación integral.
○ Desarrollar recomendaciones de revisión: Se proponen sugerencias
y mejoras basadas en los resultados de la revisión.
○ Revisar recomendaciones con el equipo de proyecto: Se discuten y
validan las recomendaciones con el equipo para garantizar su
pertinencia y viabilidad.
○ Preparar un reporte final: Se documentan de manera formal los
resultados finales de la revisión, proporcionando una guía clara para
futuras fases del proyecto.
4. Salidas
● Informe de la inspección: El Informe de la inspección cumple la función de
documentar de manera detallada los hallazgos, conclusiones y acciones
recomendadas durante la revisión del diseño. Este informe actúa como un
registro exhaustivo que captura todos los aspectos identificados durante la
revisión, proporcionando una documentación completa de los puntos
destacados, los problemas identificados y las recomendaciones para mejorar o
corregir áreas específicas del diseño. Además, sirve como una herramienta de
referencia clave para el equipo de diseño y otras partes interesadas, facilitando
la implementación de cambios y mejoras.
● Resumen de la inspección: tiene como propósito ofrecer un resumen
ejecutivo de los aspectos más relevantes identificados durante la revisión del
diseño. Este resumen condensado destaca los puntos clave y las áreas críticas
que requieren atención inmediata o acción. El resumen se presenta de manera
clara y concisa, permitiendo a los líderes del proyecto y otras partes
interesadas obtener una visión rápida y comprensiva de los resultados de la
revisión. Así, el resumen se convierte en una herramienta eficaz para la toma
de decisiones y la asignación de recursos para abordar los aspectos más
críticos del diseño identificados durante la inspección.
5. Checklist
Inicialmente, se consideró un modelo

relacional, pero con el tiempo, se optó
¿Experimentaron dificultades o
Sí por usar la misma base de datos que el
limitaciones en el proyecto?
SUM, lo que facilitó el login de los
estudiantes
Los entregables (artefactos) son

¿Se documenta o comunica el diseño resultados de procesos organizativos.
a los desarrolladores u otros Sí Los artefactos pueden variar según el
miembros del equipo? contexto, pero el documento de
arquitectura en el diseño es esencial
El diseño de la base de datos madura

con la adquisición de nueva
¿Se realizó la revisión del diseño de información. Se establece un
la base de datos en el momento Sí cronograma para entregables y
adecuado? configuraciones iniciales, pero con el
tiempo, se reutiliza código para nuevos
requerimientos
Los cambios en el diseño se evalúan en

función de atributos de calidad
¿Se han considerado y documentado
definidos por la empresa. Si un cambio
los posibles impactos de los cambios Sí
afecta negativamente estos atributos, no
futuros en el diseño del software?
se realiza; de lo contrario, se
implementa
¿Utilizan métodos, métricas o Algunas normas ISO 2500 o ADD dan

herramientas para evaluar la métricas específicas para el diseño.
usabilidad, accesibilidad y Sí Generalmente en el diseño se busca que
escalabilidad en el diseño de las métricas usadas pasen
software? satisfactoriamente las pruebas de
calidad. De por sí las métricas a usarse
depende del tipo de software y el

contexto organizacional
En la elección de patrones de diseño, es

esencial comprender qué problemas
resuelven. Se selecciona el patrón que
¿Se evalúa si el patrón de diseño
Sí se adapte a las necesidades
elegido es el más adecuado?
organizacionales o se basa en
arquitecturas de referencia para
software similar
Aunque se tenga un área de TI, según

sea la cantidad de trabajadores se
¿Se dan los materiales del diseño
Sí desarrollará de manera compleja o no,
para la revisión en el ciclo?
pero si se les da porque todo se da con
proyección.
Hay roles y áreas como el “área de la

gestión de la demanda”, se encargan de
contacto directo con el usuario desde la
¿Se solucionan los problemas de idea plasmada en una solicitud para
comunicación con el cliente y los Sí asegurar que se haya revisado y tenga
arquitectos? participación en el proyecto. Esto hace
que se tenga una involucramiento donde
los problemas sean resueltos de forma
natural.
¿Hay suficientes roles para poder Sí Hay muchas áreas disponibles para
desempeñarse en el ámbito laboral poder acceder, como programadores,
actual? analiticos, aseguradores de calidad, etc
6. Métricas
● Índice de Cumplimiento de Plazos (On-Time Delivery Rate):
Esta métrica se utilizará para evaluar la puntualidad en la entrega de
tareas y funcionalidades relacionadas con el diseño. El seguimiento del
Índice de Cumplimiento de Plazos permitirá verificar si las distintas
etapas del diseño se están completando dentro de los plazos
planificados. En caso de desviaciones, se podrán identificar áreas de
mejora y tomar acciones correctivas para asegurar que el diseño se
desarrolle de manera eficiente y conforme a la programación
establecida.
● Error de Estimación:
La métrica de Error de Estimación se implementará para medir la
precisión de las estimaciones realizadas en el diseño. Al comparar la
estimación original con el tiempo y los recursos reales utilizados, se
obtendrá una evaluación cuantitativa de la calidad de las estimaciones.
Esto permitirá ajustar las futuras estimaciones y mejorar la
planificación en proyectos similares. Identificar y corregir
discrepancias entre las estimaciones y la realidad contribuirá a la
eficiencia general del proceso de diseño, garantizando una gestión más
precisa de los recursos y plazos.
7. Involucrados
● Equipo de Ingeniería:
El equipo de ingeniería desempeña un papel fundamental en el diseño,
asegurando su coherencia y cumplimiento de requisitos.
● Equipo de Aseguramiento de la Calidad del Software:
Colabora estrechamente con el equipo de ingeniería, realizando
inspecciones y revisiones para garantizar la calidad del diseño antes de
su implementación. Su enfoque se centra en la identificación temprana
de posibles problemas y la mejora continua del proceso de diseño.
E. Codificación
a. Objetivo
El objetivo principal de la fase de Codificación es asegurar que las
especificaciones de diseño hayan sido correctamente implementadas. Esto
implica verificar que el código desarrollado cumpla con los requisitos
establecidos en las especificaciones y garantizar la corrección y calidad del
programa resultante.
b. Entradas
● Especificaciones de programas: son un documento fundamental que
proporciona una descripción minuciosa de los requisitos específicos
que los programas deben satisfacer durante la codificación. Este
documento detalla con precisión las funcionalidades esperadas,
restricciones y cualquier otro aspecto relevante para la implementación
del código. Su propósito principal radica en servir como guía esencial
para los programadores, asegurando que el código desarrollado cumpla
rigurosamente con los criterios y expectativas establecidos durante la
fase de codificación.
● Documentación de programas: complementa las especificaciones al
ofrecer información adicional que explora la implementación y el
funcionamiento detallado de los programas. Este componente puede
abordar aspectos como el diseño, la estructura del código, los
algoritmos utilizados y cualquier consideración especial necesaria para
la comprensión y el mantenimiento efectivo del código. La
documentación de programas desempeña un papel crucial al actuar
como una referencia exhaustiva para los desarrolladores y otros
miembros del equipo, facilitando la colaboración, la comprensión y el
mantenimiento continuo del código a lo largo del ciclo de vida del
software.
● Listado de código: representa el código fuente desarrollado por los
programadores. Este elemento es la materialización de la lógica y la
implementación definida en las especificaciones y la documentación de
programas. Su propósito central es constituir la base ejecutable del
software, representando la ejecución lógica de las instrucciones
definidas en el proceso de codificación. El código fuente es la
manifestación tangible de la creatividad y la habilidad de los
programadores, y su calidad impacta directamente en el rendimiento y
la fiabilidad del software resultante.
● Programas ejecutables: son versiones compiladas y listas para
ejecutar de los programas. Estos archivos ejecutables representan la
culminación del proceso de codificación y son la forma en que el
software se presenta y opera en un entorno de usuario final. El
propósito principal de los programas ejecutables es proporcionar una
versión funcional y lista para el uso del software desarrollado. Estos
archivos son esenciales para las pruebas finales y la implementación
efectiva del software en un entorno operativo.
● Diagramas de flujo de los programas: son representaciones gráficas
que describen la lógica y la secuencia de los programas. Estos
diagramas ofrecen una visión visual de cómo se espera que interactúen
los diferentes componentes del código. Su propósito radica en facilitar
la comprensión y la comunicación efectiva entre los miembros del
equipo de desarrollo. Los diagramas de flujo son herramientas visuales
poderosas que ayudan a los programadores a entender la estructura y la
lógica del código, facilitando la identificación de posibles mejoras y la
resolución eficiente de problemas durante la fase de codificación.
c. Proceso
Análisis de Factores de Codificación
● Implementación del control de integridad de información:
Verificación de que los mecanismos de control de integridad de
la información estén implementados correctamente en el
código.
● Implementación de reglas de autorización: Garantía de que
las reglas de autorización especificadas se apliquen de manera
efectiva en el código.
● Implementación de control de integridad de archivos:
Verificación de que los controles de integridad de archivos
estén correctamente incorporados en el código.
● Implementación de auditorías de rastreo: Asegurar que se
hayan implementado auditorías de rastreo para facilitar la
identificación y corrección de problemas.
● Implementación de procedimientos de seguridad:
Verificación de la correcta implementación de procedimientos
de seguridad en el código.
● Cumplimiento del programa con la metodología a adoptar:
Evaluación para asegurar que el código sigue la metodología
definida para el proyecto.
● Programa acorde al diseño (Correctitud): Verificación de
que el código implementado sea coherente con las
especificaciones de diseño.
● Mantenimiento del programa: Evaluación de la capacidad del
código para ser mantenido y modificado eficientemente.
● Desarrollo de procedimientos operativos: Creación y
documentación de procedimientos operativos relacionados con
el código desarrollado.
d. Salidas
● Listado de defectos encontrados: documento integral que enumera y
describe exhaustivamente los defectos identificados durante la fase de
codificación. Cada defecto se registra con detalles precisos, incluyendo
su naturaleza, ubicación en el código y cualquier otra información
relevante. El propósito principal de este listado es proporcionar un
registro detallado de los problemas y errores identificados, sirviendo
como un recurso clave para el equipo de desarrollo y el equipo de
aseguramiento de calidad del software.
Este documento es esencial para la mejora continua del proceso de
codificación, ya que permite a los programadores revisar y abordar
cada defecto de manera específica. Además, el listado de defectos
encontrados facilita la comunicación efectiva entre los miembros del
equipo al proporcionar una referencia clara y detallada de los
problemas identificados. La información detallada en este listado es
crucial para realizar correcciones precisas y mejorar la calidad general
del código durante el desarrollo del software.
e. Checklist
La base de datos es MyBatis y JPA para

trabajar de manera más rápida el mapeo
de entidades, el cual nos ahorra y
¿Utilizan lenguajes y frameworks optimiza el tiempo.En Frontend
específicos para el backend y Sí utilizamos Thymeleaf, Javascript y
frontend? JQuerry. Y base de datos como tal es
Oracle en su versión 19, para trabajarlo
de manera relacional y Roper de
mensajería
Lo que se prima es que se tenga

conocimiento para trabajar en
actividades frontend y backend, como
también en base de datos. En San
¿Se ha determinado un equipo de
Marcos tenemos pocos sistemas (19 o
desarrollo con roles mínimos Sí
más) y como tal especializarse en esos
establecidos?
dos puntos es bueno pero se necesita a
otros tipos de actividades. En general
este conocimiento lo tenemos todos los
miembros del equipo.
Proceso de manejo de bugs:
-Reporte, registro y descripción del bug.

¿Se han solucionado todos los -Replicación en un ambiente de pruebas
No
defectos y se han registrado? con una base de datos productiva.
-Priorización en ambiente productivo
para evitar interferencias con otros
sistemas
Uso de Jira para organizar tareas en

¿Utilizan herramientas para
frentes, seguimiento semanal y
gestionar los requisitos u objetivos Sí
documentación compartida para el pase a
cumplidos?
producción.
Requisitos no implementables requieren

¿Se toma alguna acción con los
reuniones con el área de análisis para
requisitos que no se pueden Sí
llegar a acuerdos y actualizar los
implementar?
artefactos correspondientes
Enfoque en manuales concisos con

¿Se consideran puntos importantes
Sí imágenes como ayuda visual para los
en el manual de usuario?
usuarios
Hay sistemas heredados que tenemos

como legacy, para esos casos le damos
mantenimiento y seguimos trabajando
¿Hubo un proceso de selección de con esas tecnologías. Para nuevas
Sí
tecnologías y frameworks? iniciativas, vemos cual se acomoda
mejor y darle uso, así como actualizamos
en el caso de Roper o Angular que no se
estuvieron usando antes.
Se consideran generalmente las pruebas

¿Se consideran métricas críticas en
Sí de carga, los umbrales de respuesta y un
el desarrollo?
apoyo en la herramienta JMeter.
f. Métricas
● Número de Defectos por Línea de Código (Defects per KLOC):
proporciona una medida cuantitativa crucial al evaluar la calidad del
código desarrollado durante la fase de codificación. Al calcular la
cantidad de defectos identificados por cada mil líneas de código, esta
métrica ofrece una visión precisa de la fiabilidad del software. Un
menor número de defectos por KLOC sugiere una mayor calidad y
menor propensión a errores en el código. Esta métrica se utiliza para
evaluar la eficacia de las prácticas de codificación, identificar áreas de
mejora y realizar comparaciones a lo largo del tiempo para medir el
progreso en la gestión de defectos.
● Complejidad Ciclomática:
evalúa la complejidad del código, identificando áreas que podrían
requerir una atención adicional y pruebas intensivas. La complejidad
ciclomática mide la complejidad estructural del código fuente,
teniendo en cuenta la cantidad de caminos independientes a través del
código. Un valor más alto indica una mayor complejidad y,
potencialmente, una mayor dificultad para entender, mantener y probar
el código. Esta métrica se utiliza para anticipar áreas de riesgo en el
código, guiar la asignación de recursos para pruebas y revisiones más
intensivas, y proporcionar información clave para la mejora continua
de la calidad del código.
g. Involucrados
Equipo de Ingeniería
● Gerente de proyecto: Supervisa la implementación y asegura la
alineación con los objetivos del proyecto.
● Grupo de programación: Programadores responsables de la
codificación y desarrollo del software.
Equipo de Aseguramiento de la Calidad del Software
● Líder de Aseguramiento de la Calidad del Software: Coordina las
actividades de aseguramiento de calidad durante la codificación.
● Analistas de Aseguramiento de la Calidad del Software Senior y/o
Semi-senior: Participan en la revisión y evaluación del código para
garantizar la calidad y conformidad con los estándares establecidos.
F. Pruebas
a. Objetivo
La fase de pruebas se propone determinar con precisión si el software
funcionará correctamente cuando se ejecute. Su principal finalidad es
garantizar la calidad y confiabilidad del software, identificando posibles
defectos antes de su implementación en un entorno de producción. Esto no
solo asegura que el software cumpla con los requisitos funcionales, sino
también con los aspectos no funcionales, como rendimiento, seguridad y
usabilidad. La verificación exhaustiva durante esta fase contribuye a ofrecer
un producto final que cumple con las expectativas y necesidades de los
usuarios de manera eficiente y efectiva.
b. Entradas
● Planes de pruebas:
Documentación detallada de las estrategias y enfoques de prueba.
● Pruebas funcionales y no funcionales:
Especificaciones detalladas de los casos de prueba, cubriendo tanto los
aspectos funcionales como los no funcionales del software.
● Datos de prueba:
Conjunto de datos diseñados para abordar diferentes escenarios de uso
y casos límite.
● Resultados de las pruebas:
Información sobre la ejecución de pruebas previas y resultados
obtenidos.
c. Proceso
i. Verificar la Construcción de Datos / “Scripts” de Prueba
● Diseño de archivos de prueba:
Creación de archivos que representen situaciones reales de uso.
● Ingreso de los datos de prueba:
Introducción de datos diseñados para validar la funcionalidad y el
rendimiento.
● Análisis de los resultados esperados:
Evaluación de los resultados esperados frente a los obtenidos.
● Creación de casos de prueba:
Desarrollo de casos específicos para abordar escenarios críticos.
ii. Verificar la Ejecución de la Prueba
● Prueba manual, de regresión y funcional:
Ejecución de pruebas manuales, pruebas de regresión para garantizar
que las nuevas implementaciones no afecten el funcionamiento
existente, y pruebas funcionales para validar la lógica del software.
● Prueba de autorización:
Verificación de la correcta autorización de usuarios.
● Prueba de integridad:
Confirmación de que los datos mantienen su integridad durante y
después de la ejecución.
● Prueba de seguridad:
Evaluación de la robustez del sistema ante posibles vulnerabilidades.
iii. Verificar el Registro de los Resultados de la Prueba
● Verificación del registro de los resultados de la prueba:
Revisión de los registros para asegurar una documentación precisa y
completa de los resultados.
d. Salidas
● Planes de prueba verificados:
Documentos de estrategias de prueba actualizados y validados.
● Muestra de transacciones de prueba verificadas:
Ejemplos concretos de transacciones que han sido sometidas a pruebas
y han pasado la verificación.
● Desvío de los resultados esperados documentados:
Informes detallados sobre cualquier desviación de los resultados
esperados.
¿Todos los pasos fueron Se dan objetivos claros que se deben cumplir
realizados como se Sí en plazos determinados para no interrumpir
especificaron? el desarrollo del proyecto.
Dependiendo del rubro. Es frecuente un

ambiente poco favorable debido a peticiones
de horas extras para culminar objetivos que
¿Se estableció un ambiente de
no se han terminado en el día los atrasos
prueba apropiado para realizar No
ocasionados por caídas de servicio, pases de
la prueba del software?
proyectos ocurren a menudo en el área de
bancos. En el área de seguros se es más
flexible en este aspecto.
Se da un plazo de tiempo, este se gestiona

¿Se fijó un tiempo adecuado
Sí previamente para realizar cada etapa del
para esta etapa?
proyecto en un periodo óptimo de tiempo.
Dependiendo de los requerimientos de la

empresa y de la empresa en sí, muchas
¿Se fijaron los recursos
Sí compran recursos a empresas de terceros
adecuados para esta etapa?
como IBM, otras diseñan recursos
específicos para su caso.
Generalmente se crea y maneja su propia

¿Fueron creados los datos de
data, por equipos encargados de crearla y
prueba necesarios para probar Sí
mantenerla actualizada, usualmente de cada
adecuadamente el software?
dos meses a cada 4 meses.
Si bien sí debe haber un plan de pruebas en

¿Fueron programadas todas las
cada Sprint, en la práctica se ve muy poco
técnicas de verificación
esta situación, sin embargo, este siempre está
indicadas en el plan de prueba Sí
al momento de iniciar el proyecto debido a
para ser ejecutadas durante este
que se encuentra ahí el alcance, objetivos,
paso?
dependencias, cronogramas, riesgos, etc.
Usualmente se tiene una casuística y si se

¿Se han documentado los Sí tienen diferencias en valores numéricos, se
resultados esperados y los
calcula profundamente para verificar esta
actuales cuando existe una
diferencia de manera certera. No es muy
diferencia entre ellos? común pero se verifican todas las entidades

implicadas para evitar los fallos
Generalmente se gestiona con manejos de

¿Se ha establecido un
backups y se reúnen a los equipos para
procedimiento para asegurar las
Sí solucionar los incidentes, dependiendo de la
acciones/ resolución apropiada
magnitud, se hacen a horas no laborales
de los defectos?
incluso.
f. Métricas
● Complejidad de los Requerimientos. Evalúa la complejidad de los
requisitos del software.
● Cobertura de Requerimientos (CR). Mide la extensión en la que los
requisitos abarcan todas las necesidades y expectativas del cliente.
● Efectividad de Casos de Prueba. Evalúa la eficacia de los casos de
prueba en la identificación de defectos.
● Tiempo de Ejecución de Pruebas. Mide el tiempo necesario para
ejecutar todas las pruebas planificadas.
● Densidad de Defectos por Funcionalidad. Indica la cantidad de
defectos encontrados en una funcionalidad específica.
● Índice de Reproceso. Mide la proporción de trabajo que debe repetirse
debido a defectos encontrados.
g. Involucrados
● Gerente de proyecto.
Supervisión general y coordinación.
● Representante del grupo de análisis de requerimientos.
Asegura la alineación de las pruebas con los requisitos.
● Representante del grupo de diseño.
Verificación de la implementación según el diseño.
● Representante del grupo de analistas desarrolladores.
Colaboración en la identificación y resolución de problemas
durante las pruebas.
● Grupo de testeo.
Ejecución de casos de prueba y reporte de resultados.
● Líder de Aseguramiento de la Calidad del Software.
Supervisión general de la calidad del proceso de prueba.
● Analistas de aseguramiento de la calidad del software
Senior y/o Semi-senior.
Evaluación crítica de los resultados y procesos de prueba.
G. Instalación
a. Objetivo
El objetivo primordial de la fase de instalación es llevar a cabo una
verificación exhaustiva del proceso de instalación, ya sea para la
implementación de nuevos sistemas o para la actualización de versiones
existentes. Esta fase se enfoca en garantizar que el software se instale de
manera correcta y eficiente, minimizando los riesgos asociados con la
introducción de cambios en el entorno de producción.
b. Entradas
● Plan de instalación:
Documento detallado que describe la estrategia y los pasos para la
instalación.
● Diagrama de flujo de la Instalación:
Representación visual de los procesos y decisiones relacionadas con la
instalación.
● Resultados de la verificación de instalaciones especiales:
Información sobre cualquier verificación específica requerida para
instalaciones especiales.
● Documentación de pase a producción:
Documento que autoriza la transición del software al entorno de
producción.
● Instrucciones y procedimientos para los nuevos usuarios:
Guía detallada para usuarios que aborda la operación del software
después de la instalación.
● Resultado del proceso de instalación:
Información sobre el éxito o cualquier problema durante el proceso de
instalación.
c. Proceso
i. Verificación de la Instalación de Nuevo Software
● Integridad del sistema/versión anterior asegurado:
Verificación de que la nueva instalación no afecta la integridad del
sistema existente.
● Recuperación ante fallas de la instalación:
Evaluación de la capacidad del sistema para recuperarse en caso de
fallos durante la instalación.
● Control de acceso durante la instalación:
Aseguramiento de que el acceso durante la instalación esté controlado
según las políticas de seguridad.
● Instalación acorde a la metodología:
Confirmación de que la instalación sigue las mejores prácticas y
metodologías establecidas.
● Instalación en producción de los programas indicados en la fecha
asignada:
Verificación de que la instalación se realiza según el cronograma
planificado.
● Puesta a disposición de instrucciones de instalación:
Confirmación de que las instrucciones necesarias están disponibles
para los usuarios.
● Procedimientos operativos:
Validación de que los procedimientos operativos son efectivos después
de la instalación.
ii. Verificación de la Instalación de Cambios de Software
● Poner a la aplicación modificada en producción:
Confirmación de la implementación exitosa de cambios en la
aplicación.
● Evaluar la eficiencia de los cambios:
Evaluación de la mejora de la eficiencia con los cambios realizados.
● Monitorear la exactitud de los cambios:
Supervisión continua para garantizar la precisión de los cambios.
● Mantener actualizadas con las últimas versiones disponibles, los
ambientes de prueba y producción:
Actualización de ambientes para reflejar las últimas versiones
disponibles.
iii. Seguimiento en Producción
● Monitoreo de las salidas del aplicativo:
Supervisión continua de las salidas del aplicativo después de la nueva
instalación.
● Documentación mediante el uso de un formulario:
Registro estructurado de cualquier indicio de problemas detectados.
iv. Documentar los Problemas
● Documentación de problemas detectados:
Registro detallado de los problemas encontrados durante el monitoreo.
● Evaluación del riesgo asociado a ese problema:
Análisis de la gravedad y riesgos asociados a cada problema.
d. Salidas
● Reporte de recuperación ante fallas:
Documento detallado sobre la capacidad de recuperación del sistema.
● Reporte de notificación de monitoreo de cambios de software:
Informe sobre las observaciones y notificaciones durante el monitoreo
de cambios.
● Reporte de problemas causados por cambios de Software:
Informe que documenta los problemas detectados y evaluación de su
riesgo asociado.
En desarrollo, los nuevos miembros del equipo

suelen depender de los más experimentados
hasta que adquieren confianza en la aplicación.
¿Puede un programador
En sistemas antiguos (no DevOps), es esencial
cometer errores importantes
Sí que no haya cajas negras, lo que significa que
en un programa web o de
no se deben omitir pasos específicos, como la
computadora?
compilación. La documentación y las pruebas
personales son fundamentales antes de pasar a
producción
Cuando no existe documentación, se recurre a

la decompilación del código fuente para aplicar
¿Se toma alguna acción
soluciones de ingeniería inversa. En general, se
cuando no hay Sí
sugiere reemplazar aplicativos sin
documentación disponible?
documentación, aunque esta decisión depende
de la empresa
Los procesos manuales de despliegue suelen

basarse en correos o sistemas de seguimiento,
¿Se sigue un procedimiento mientras que en un entorno DevOps, las
para monitorear los cambios Sí comunicaciones se gestionan de manera más
en el despliegue del sistema? eficiente a través de herramientas
especializadas. Se describen diferencias entre
ambas prácticas
Sí Los riesgos altos y medios deben abordarse

¿Se abordan los riesgos no
antes de avanzar a la siguiente etapa, ya que
corregidos de alguna
pueden ser bloqueantes. Los riesgos bajos
manera? pueden permitirse en ciertos casos
La organización puede no autorizar el

¿Los errores de baja despliegue si se detectan demasiados defectos,
prioridad acumulados se incluso si son de riesgo bajo. Se plantea el
No
mantienen en el backlog sin dilema de cumplir con una ley o normativa y la
abordar? presión para decidir entre obviar la
documentación o liberar el sistema con defectos
En instituciones públicas, es común enfrentar

¿Los usuarios suelen múltiples incidencias en un día. La mesa de
presentar quejas o reportes Sí ayuda desempeña un papel esencial en la
sobre el aplicativo? recepción, tipificación y registro de incidentes
para oportunidades de mejora
En el entorno DevOps, se hace hincapié en la

importancia de la documentación y el
¿Existe un papel de
monitoreo constante durante el proceso de
monitoreo continuo y Sí
despliegue. El equipo de desarrollo está
contribuye al sistema?
presente hasta que el usuario confirma que todo
está en orden
f. Métricas
● Tiempo de Instalación. Mide la duración total del proceso de instalación.
● Éxito de la Recuperación ante Fallas. Evalúa la efectividad del sistema para
recuperarse de fallos durante la instalación.
● Actualización de Ambientes. Verifica la frecuencia y eficiencia de la
actualización de ambientes de prueba y producción.
● Cumplimiento del Cronograma de Instalación. Mide la precisión en
cumplir con los plazos programados para la instalación.
g. Involucrados
● Gerente de proyecto.
Supervisión general y coordinación.
● Grupo de instalación de software.
Responsable de la implementación y verificación de la instalación.
● Grupo de operaciones.
Colaboración en la validación de procedimientos operativos.
● Líder de Aseguramiento de la Calidad del Software.
Supervisión general de la calidad del proceso de instalación.
● Analistas de aseguramiento de la calidad del software Senior y/o
Semi-senior.
Evaluación crítica de los resultados y procesos de instalación.

G5 - Plan de Aseguramiento de Calidad - InformeFinal

Cargado por

Información del documento

Descripción original:

Título original

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

G5 - Plan de Aseguramiento de Calidad - InformeFinal

Cargado por

Copyright:

Formatos disponibles

Plan de aseguramiento de la calidad

Plan de Aseguramiento de Calidad

El objetivo de la fase de Planificación es establecer las bases y los

lineamientos para llevar a cabo el proyecto de desarrollo de software de

manera efectiva y eficiente. Esto implica determinar con precisión qué

recursos serán necesarios y estarán disponibles para llevar a cabo el proyecto

de software asociado. Al hacerlo, se busca prever y mitigar posibles

obstáculos o retrasos que puedan surgir durante el desarrollo.

En esta etapa, se busca responder a preguntas críticas como:

● ¿Qué recursos humanos serán requeridos y en qué roles?

● ¿Cuánto tiempo se estima que tomará completar cada fase del

● ¿Cuáles son los costos asociados con el proyecto?

● ¿Qué herramientas o tecnologías se necesitarán para llevar a cabo el

En resumen, el objetivo es proporcionar una hoja de ruta clara y detallada para

el proyecto de desarrollo de software, lo que permite a los equipos trabajar de

manera coordinada y eficaz hacia la consecución de los objetivos del proyecto.

1. Estimación del proyecto y método utilizado para realizarla:

La estimación del proyecto es una evaluación sistemática y anticipada

de los recursos necesarios para llevar a cabo el proyecto de desarrollo

de software. Esto incluye factores como el tiempo, los recursos

humanos, la infraestructura tecnológica y los costos asociados.

El método utilizado para realizar esta estimación puede variar según

las prácticas y las herramientas disponibles. Puede incluir enfoques

basados en la experiencia pasada, análisis de similares proyectos

previos, técnicas de descomposición y estimaciones paramétricas

utilizando herramientas especializadas.

2. Plan de desarrollo (de software) del proyecto y descripción del

El plan de desarrollo es un documento integral que delineará cómo se

llevará a cabo el proyecto de desarrollo de software. Incluye una

secuencia de actividades, roles y responsabilidades, así como los

entregables esperados en cada etapa.

La descripción del proceso de desarrollo a utilizar en el proyecto es

una especificación detallada de la metodología o enfoque que se

seguirá durante el desarrollo del software. Puede ser ágil, en cascada,

en espiral u otros modelos. Proporciona pautas sobre cómo se realizará

el trabajo, cómo se gestionarán los cambios y cómo se llevará a cabo la

integración y las pruebas.

i. Verificación de la Estimación del Proyecto

La verificación de la estimación del proyecto constituye un proceso

esencial que se desarrolla con el propósito de analizar y autenticar la

exactitud de las estimaciones realizadas previamente en la fase de

planificación del proyecto. Este procedimiento tiene como finalidad

asegurar que las estimaciones sean coherentes con las condiciones y

requisitos actuales del proyecto, con el fin de que sean verdaderamente

viables y reflejan la realidad.

En la hipótesis de que se detecten desviaciones sustanciales entre las

estimaciones originales y la situación presente del proyecto, se

establece la posibilidad de realizar modificaciones y ajustes en el plan

del proyecto. Estos ajustes pueden abarcar aspectos relacionados con la

asignación de recursos, plazos y presupuesto, con el propósito de

asegurar que el proyecto siga siendo realista y acorde con las

ii. Verificación del Estado del Proyecto

La verificación del estado del proyecto es una especie de control para

comprobar si el proyecto está avanzando como se esperaba. Significa

observar si se están cumpliendo los hitos y si se están usando los

recursos según lo planeado. Si notamos problemas importantes o cosas

que no van como se había previsto, tomamos medidas para corregir el

rumbo y asegurarnos de que el proyecto siga en la dirección correcta.

Esta etapa nos ayuda a mantener el proyecto en el camino correcto y a

solucionar cualquier problema que surja en el camino.

La conclusión de la etapa de planificación y verificación del proyecto implica

la generación de diversos documentos y datos relevantes. Estos incluyen