Grupo 3 - Plan de Aseguramiento - Proyecto Final

Universidad Nacional Mayor de San Marcos.
Facultad de Ingeniería de Sistemas e Informática.
ASEGURAMIENTO DE LA
CALIDAD DEL SOFTWARE
Grupo 3:
Barbosa Motta, Branimir Rai.
Chavez Echevarria, Andres David.
Coronel Vilca, Brisa Valeria.
Jauregui Diaz, Yajahira Ysabel.
Matos Ramos, Franco Antocio.
Mayor Coloma, Fabrizio.
Valega Vidarte, Renzo Omar.
2023
Universidad
Aseguramiento de la Calidad del Software Nacional Mayor
de San Marcos
Contenido
A. Planificación 2
B. Requerimientos 10
C. Análisis 18
D. Diseño 25
E. Codificación 33
F. Pruebas del Sistema 40
G. Instalación 47
1
Universidad
de San Marcos
A. Planificación
Contenido
A.1. Objetivo 3
A.2. Entrada 3
A.3. Proceso 4
A.3.1. Verificación de la Estimación del Proyecto 4
A.3.2. Verificación del Estado del Proyecto 4
A.4. Salidas 5
A.5. Lista de Verificación (Checklist) 7
A.6. Métricas 8
A.7. Involucrados 9
A.7.1 Equipo de Ingeniería 9
A.7.2 Equipo de Aseguramiento de calidad 9
2
Universidad
de San Marcos
A.1. Objetivo
En este punto, se define el propósito o los objetivos específicos que se pretenden

lograr a través del proceso de aseguramiento de calidad. Esto podría incluir la mejora de la
calidad de un producto o servicio, la reducción de defectos o errores, la optimización de
procesos, o cualquier otro objetivo relevante relacionado con la calidad. Establecer objetivos
claros es esencial para garantizar que el aseguramiento de calidad esté alineado con las metas
de la organización.
A.2. Entrada
La identificación y gestión de las entradas es esencial para planificar y llevar a cabo el

aseguramiento de calidad de manera efectiva. Aquí hay más información sobre cómo abordar
este aspecto:
❖ Documentación: Puede incluir documentos relacionados con estándares de calidad,

especificaciones técnicas, procedimientos, planos, manuales, políticas, y cualquier
otro tipo de documentación relevante.
❖ Requisitos del cliente: Los requisitos del cliente son una entrada crítica. Esto podría
incluir contratos, acuerdos de nivel de servicio (SLA), expectativas del cliente y
cualquier solicitud específica que el cliente haya planteado.
❖ Datos históricos: La información sobre proyectos anteriores o resultados de calidad

pasados puede ser valiosa para aprender de experiencias pasadas y evitar errores
previamente identificados.
❖ Recursos: Esto podría incluir personal, hardware, software, equipos de prueba y otros
recursos necesarios para realizar las actividades de aseguramiento de calidad.
❖ Planes y programas: La planificación también puede incluir programas de trabajo,

calendarios, asignación de tareas y cualquier plan específico relacionado con el
aseguramiento de calidad.
❖ Contexto: Es importante tener en cuenta el contexto en el que se realizará el

aseguramiento de calidad. Esto puede incluir consideraciones ambientales, de
seguridad, reglamentarias y cualquier otro factor que afecte al proceso.
3
Universidad
de San Marcos
A.3. Proceso
A.3.1. Verificación de la Estimación del Proyecto
La verificación de la estimación del proyecto implica revisar y validar las

estimaciones realizadas por el equipo de desarrollo y los responsables del proyecto.
Algunos de los aspectos clave que se verifican durante este proceso incluyen:
❖ Estimación de tiempo: Se verifica si el tiempo estimado para completar las

diferentes etapas del proyecto es realista y coherente con la magnitud del trabajo
requerido. Esto implica evaluar si se han tenido en cuenta todos los factores que
pueden influir en la duración del proyecto, como la complejidad de las tareas, la
disponibilidad de recursos y posibles riesgos.
❖ Estimación de recursos: Se verifica si los recursos necesarios, como personal,

hardware y software, se han estimado adecuadamente. Esto implica asegurarse de que
se hayan considerado todos los roles necesarios y que el equipo cuente con las
habilidades y la capacitación requerida.
❖ Estimación de costos: Se verifica si los costos asociados al proyecto, incluyendo

salarios, licencias de software, hardware y otros gastos, se han calculado
correctamente. Esto asegura que el proyecto se mantenga dentro del presupuesto
definido.
❖ Contingencias y riesgos: Se revisan las estimaciones a la luz de posibles riesgos y

contingencias que puedan surgir a lo largo del proyecto. Se consideran planes de
mitigación para abordar estos riesgos si se materializan.
A.3.2. Verificación del Estado del Proyecto
Algunos aspectos clave que se verifican durante la verificación del estado del
proyecto incluyen:
❖ Avance del cronograma: Se verifica si el proyecto se está desarrollando de acuerdo

con el cronograma planificado. Esto implica evaluar si las tareas se están completando
a tiempo y si no se están acumulando retrasos significativos.
❖ Presupuesto: Se verifica si el gasto del proyecto se encuentra dentro de los límites

presupuestarios establecidos. Esto incluye el seguimiento de los costos en relación
4
Universidad
de San Marcos
con las estimaciones y la identificación temprana de posibles desviaciones

presupuestarias.
❖ Calidad del software: Se verifica si el software que se está desarrollando cumple con
los estándares de calidad y las especificaciones definidas. Esto puede incluir la
revisión de métricas de calidad, pruebas y auditorías para asegurarse de que el
software se ajuste a los requisitos y está libre de defectos significativos.
❖ Riesgos y problemas: Se verifica si se están gestionando adecuadamente los riesgos

y los problemas del proyecto. Se identifican posibles obstáculos y se evalúa si se están
tomando medidas para abordarlos.
❖ Entregables e hitos: Se verifica si se están cumpliendo los entregables y los hitos del
proyecto según lo programado. Esto incluye la revisión de documentos, códigos
fuente, pruebas y otros elementos clave del proyecto.
A.4. Salidas
Las salidas son esenciales en la gestión de proyectos y procesos por varias razones:
❖ Medición del progreso: Las salidas permiten medir el progreso de un proyecto o

proceso. Al comparar las salidas con los objetivos y requisitos previamente
establecidos, se puede determinar si se está avanzando de manera adecuada hacia los
objetivos finales.
❖ Control de calidad: Las salidas se utilizan para evaluar la calidad del trabajo
realizado. Se pueden comparar con estándares de calidad y especificaciones para
asegurarse de que cumplen con los criterios de calidad establecidos.
❖ Comunicación: Las salidas proporcionan una forma de comunicar los resultados y

avances a los interesados del proyecto o proceso. Esto es fundamental para mantener a
todas las partes involucradas informadas sobre el estado de la iniciativa.
❖ Documentación: Las salidas a menudo incluyen documentos y registros que registran

lo que se ha hecho y los resultados obtenidos. Estos documentos pueden ser
importantes para fines de auditoría, revisión y referencia futura.
❖ Entradas para la siguiente etapa: Las salidas de una fase o etapa de un proyecto
suelen convertirse en las entradas para la siguiente fase o etapa. Esto ayuda a
garantizar una transición suave y efectiva entre las partes del proyecto.
5
Universidad
de San Marcos
Las salidas pueden variar según el tipo de proyecto o proceso. En un proyecto de

desarrollo de software, por ejemplo, las salidas pueden incluir documentos de diseño, código
fuente, pruebas realizadas, manuales de usuario y el software mismo. En un proceso de
fabricación, las salidas pueden ser productos físicos, como automóviles o dispositivos
electrónicos.
En resumen, las salidas representan los resultados tangibles e intangibles de un

proyecto o proceso y son fundamentales para evaluar, controlar y comunicar el progreso y los
logros a lo largo del ciclo de vida de la iniciativa.
6
Universidad
de San Marcos
A.5. Lista de Verificación (Checklist)
Ítem Cumple Descripción
Nosotros para poder desarrollar el software

¿El equipo del proyecto tiene
en San Marcos sí tenemos un plan de
conocimiento del proceso de
Sí proyecto anual, haciendo una proyección de
desarrollo utilizado para construir el
todos los desarrollos,mantenimientos,
software 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á completo? Sí ejecutar. A su vez el plan de proyecto no
contempla el plan de comunicaciones, ya
que es parte de la metodología.
La estimación es anual, donde se

¿La estimación del proyecto está
Sí documentan los sistemas que se van a
totalmente documentada?
mantener o lanzar.
Se ha desarrollado una metodología

tradicional en la mayor parte de proyectos
¿El proceso de desarrollo está
Sí donde se da una documentación detallada.
totalmente documentado?
Quiere decir que se tienen documentos de
análisis, diseño, desarrollo y pruebas.
La estimación está relacionada al tiempo, en

¿El método de estimación utilizado
base a esto se puede conocer el costo. El
para el proyecto, es razonable
Sí tiempo es evaluado por los líderes de
respecto de las características del
desarrollo, análisis, arquitecto de software y
mismo?
DBA.
¿La estimación efectuada es El plan es a futuro, por lo tanto no siempre

razonable como para completar el es exacta; a veces se presentan incidentes lo
Sí
proyecto según lo especificado en el que conlleva a un incumplimiento del
plan? cronograma.
Existe un solo entregable que se remite de

¿El equipo del proyecto tiene un
forma mensual, donde se detalla el conjunto
método definido para determinar e Sí
de actividades que hizo cada uno de los
informar el estado del mismo?
integrantes del proyecto.
7
Universidad
de San Marcos
A.6. Métricas
❖ Capacidad de Carga de Trabajo
Definición: Se refiere a la medida de la capacidad del software para manejar

eficazmente la cantidad de datos y tareas requeridas en el proceso de planificación.
Objetivo: Evaluar si el software es capaz de manejar la carga de trabajo necesaria sin

degradar significativamente el rendimiento.
Significado: Es fundamental, ya que un software que no puede manejar la cantidad de

datos y tareas necesarios podría resultar en planificaciones incompletas o ineficientes.
Fórmula:
Capacidad de Carga de Trabajo (%) = (Cantidad de tareas manejadas con éxito /
Cantidad total tareas requeridas) * 100
Escala: Se expresa en términos de porcentaje, donde el 100% indicaría que el

software es capaz de manejar con éxito toda la carga de trabajo requerida en la
planificación.
❖ Productividad del Equipo de Desarrollo
Definición: Mide la eficiencia del equipo en la creación de software. Se expresa en

términos de la cantidad de trabajo que el equipo puede completar en una unidad de
tiempo, generalmente en horas-hombre por mes o semana.
Objetivo: Evaluar la eficiencia del equipo de desarrollo en la etapa de planificación.
Significado: Es esencial para la planificación, ya que proporciona una medida

cuantitativa de la eficiencia del equipo y puede ayudar a identificar áreas que
requieren mejoras o ajustes en la asignación de recursos.
Fórmula:
Productividad = (Cantidad de trabajo completado) / (Número de horas-hombre
invertidas) * 100
Escala: Se expresa en términos de porcentaje, donde 0% representa la falta de trabajo

completado y 100% indica que se ha completado todo el trabajo planificado.
8
Universidad
de San Marcos
A.7. Involucrados
A.7.1 Equipo de Ingeniería
❖ Jefe del Proyecto:

El jefe de proyecto es responsable de liderar el equipo de ingeniería y
supervisar todas las actividades relacionadas con el desarrollo del software.
Debe asegurarse de que el equipo esté alineado con los objetivos del proyecto
y cumpla con los estándares de calidad establecidos.
A.7.2 Equipo de Aseguramiento de calidad
❖ Líder de Aseguramiento de la Calidad del Software:

Este rol tiene la responsabilidad de supervisar y dirigir todas las
actividades relacionadas con el aseguramiento de calidad. Asegurar que se
sigan los estándares de calidad y que se implementen las prácticas de QA de
manera efectiva en todo el proyecto.
9
Universidad
de San Marcos
B. Requerimientos
Contenido
B.1 Objetivo 11
B.2 Entradas 11
B.3 Proceso 12
B.3.1 Realizar un análisis de factores a verificar 12
B.3.2 Conducir un “walkthrough” de requerimientos 13
B.4 Salidas 14
B.5 Lista de Verificación (Checklist) 15
B.6 Métricas 16
B.7 Involucrados 16
B.7.1 Equipo de ingeniería 16
B.7.2 Equipo de Aseguramiento de calidad de software 17
10
Universidad
de San Marcos
B.1 Objetivo
El objetivo principal de este proceso es asegurar que el software desarrollado cumple

con las expectativas y necesidades del usuario final, así como con los estándares de calidad
de la organización. Esto se logra mediante la identificación clara y la comprensión precisa de
los requisitos del usuario, así como a través de la verificación y validación efectiva de estos
requisitos durante todas las etapas del desarrollo del software. Además, el objetivo es
garantizar que los requisitos sean comprensibles, no ambiguos y completos para evitar
malentendidos y asegurar un desarrollo sin problemas del producto final.
B.2 Entradas
Esta documentación ayuda a garantizar que el software cumpla con las expectativas y
necesidades del usuario final, lo que es fundamental para la calidad del producto. Los
documentos de especificaciones de usuario que podrían ser necesarios incluyen:
❖ Documento de Requisitos del Usuario (URD): Este documento es fundamental, ya

que establece las necesidades y expectativas del usuario final en un formato accesible
para todas las partes interesadas. Proporciona la visión general del proyecto y sirve
como referencia clave para la toma de decisiones y la evaluación de la calidad.
❖ Casos de Uso: Los casos de uso son esenciales para comprender cómo los usuarios
interactúan con el sistema y qué funcionalidades son críticas. Ayudan a definir las
interacciones clave y las expectativas de los usuarios, lo que es esencial para la
calidad del software.
❖ Historias de Usuario: Si se está utilizando una metodología ágil, las historias de

usuario son cruciales para definir las funcionalidades desde la perspectiva del usuario.
Ayudan a priorizar el trabajo y a mantener el enfoque en proporcionar un valor real al
usuario.
❖ Documentación de Casos de Prueba: Los casos de prueba son vitales para

garantizar la calidad del software. Proporcionan una guía detallada para verificar que
el software cumple con los requisitos del usuario. La calidad se mide en gran parte por
la capacidad del software para superar con éxito estos casos de prueba.
❖ Documentación de Aprobación del Usuario: La aprobación del usuario es un hito

crítico en el ciclo de desarrollo del software. Este documento garantiza que los
usuarios finales estén satisfechos con las especificaciones y que sus expectativas se
11
Universidad
de San Marcos
han tenido en cuenta. Además, proporciona una base para evitar desviaciones
significativas en el proceso de desarrollo.
B.3 Proceso
B.3.1 Realizar un análisis de factores a verificar
El análisis de factores a verificar en un proyecto de software es un paso crítico

para asegurar que el producto final cumpla con las expectativas de los usuarios y las
necesidades del negocio. En este proceso, se examinan minuciosamente una serie de
elementos que abarcan desde los requisitos iniciales hasta la implementación y el
soporte post-implementación. La identificación y verificación de estos factores
permiten mitigar riesgos, garantizar la calidad del software y, en última instancia,
alcanzar el éxito del proyecto. A continuación, explicaremos los cinco factores clave
que merecen una atención prioritaria en este análisis
❖ Requisitos del usuario: Verificar que los requisitos del usuario estén
claramente definidos, documentados y aprobados es esencial, ya que estos
requisitos son la base del proyecto y determinan el éxito en términos de
satisfacción del usuario.
❖ Requisitos funcionales: Verificar que todas las funcionalidades requeridas

estén implementadas y funcionen correctamente es crítico para garantizar que
el software haga lo que se supone que debe hacer.
❖ Seguridad: Verificar que el software esté protegido contra amenazas de

seguridad es de suma importancia, ya que la seguridad es un factor crucial en
la mayoría de los proyectos de software.
❖ Calidad del código: Verificar que el código fuente cumpla con las mejores
prácticas de desarrollo de software es fundamental para garantizar la
mantenibilidad y el rendimiento a largo plazo del sistema.
❖ Pruebas de regresión: Verificar que las actualizaciones o correcciones no

afecten negativamente las funcionalidades existentes es importante para
garantizar que las características previamente funcionales sigan siendo
funcionales después de cambios en el software.
12
Universidad
de San Marcos
B.3.2 Conducir un “walkthrough” de requerimientos
Un "walkthrough" de requerimientos es una práctica efectiva para garantizar

que todos los miembros del equipo comprendan y estén de acuerdo en lo que se
espera del proyecto. También contribuye a evitar malentendidos costosos y retrabajos
en etapas posteriores del desarrollo del software. Tienen como proceso básico:
❖ Preparación:
➢ Identificar a los participantes: Reúne a un grupo de personas que estén
familiarizadas con el proyecto y tengan diferentes perspectivas, como
analistas de negocios, desarrolladores, testers y representantes del
cliente.
➢ Proporcionar documentación: Distribuye previamente la
documentación de requerimientos a los participantes para que la
revisen antes de la reunión.
❖ Reunión de "Walkthrough":
➢ Presentación: El líder del "walkthrough" (que puede ser un analista de
negocios o un jefe de proyecto) inicia la reunión y presenta una visión
general de los objetivos y el alcance de la revisión de requerimientos.
➢ Revisión de requerimientos: Comienza a revisar cada requerimiento
uno por uno. Asegúrate de que los participantes comprendan el
propósito de cada requerimiento, las restricciones, y cualquier contexto
relevante.
➢ Discusión y preguntas: Anima a los participantes a hacer preguntas,
plantear dudas y expresar comentarios. Pueden surgir aclaraciones
necesarias o cambios en este proceso.
❖ Registro de hallazgos:
➢ Documenta todas las observaciones, preguntas y comentarios
realizados durante el "walkthrough". Estos pueden incluir aclaraciones
necesarias, conflictos o áreas que requieren más investigación.
❖ Resolución de problemas:
➢ Trabaja en conjunto para resolver cualquier problema o desacuerdo
identificado durante la revisión de requerimientos. Esto puede implicar
consultar al cliente, analizar el impacto en el proyecto o realizar
investigaciones adicionales.
13
Universidad
de San Marcos
❖ Actualización de la documentación:
➢ Realiza las modificaciones necesarias en la documentación de
requerimientos según las discusiones y acuerdos alcanzados durante el
"walkthrough". Esto asegura que la documentación sea precisa y
refleje los cambios acordados.
❖ Seguimiento:
➢ Realiza un seguimiento de los problemas identificados durante el
"walkthrough" para garantizar que se resuelvan a medida que avanza el
proyecto.
❖ Aprobación:
➢ Una vez que se hayan abordado todas las preocupaciones y se hayan
realizado las modificaciones necesarias, solicita la aprobación final de
los requerimientos por parte del cliente o los interesados.
B.4 Salidas
Son los resultados clave al documentar los requerimientos. Sirven como referencia a
lo largo del proyecto, incluyendo documentos de requerimientos aprobados, matrices de
rastreo, especificaciones de interfaces y más, asegurando que los requisitos estén bien
definidos y guíen el proceso de desarrollo.
❖ Documento de Requerimientos Aprobado: Es el documento principal que contiene

todos los requisitos del sistema. Debe ser aprobado por el cliente y/o el equipo de
gestión del proyecto.
❖ Historia de Uso y Casos de Uso detallados: Se proporcionan detalles adicionales

acerca de cómo se espera que los usuarios interactúen con el sistema y pueden incluir
escenarios de uso más específicos.
❖ Documentación de Entrega: Incluye manuales de usuario, guías de instalación y

otros recursos que se entregan a los usuarios finales junto con el software finalizado.
14
Universidad
de San Marcos
B.5 Lista de Verificación (Checklist)
Para que los requerimientos sean verificables

deben ser susceptibles de poder ser atendidos,
programados a nivel de software como a nivel de
¿Los requerimientos definidos
Sí procesos. En el caso de San Marcos es importante
son verificables?
estandarizar el proceso, debido a que cada facultad
tiene sus propias necesidades o formas de hacer las
cosas
¿El usuario está de acuerdo con Se debe establecer actas de conformidad para
Sí
el requerimiento definido? establecer los requerimientos
¿Los desarrolladores entienden La documentación es muy importante, se debe

Sí
los requerimientos? hacer un buen relevamiento de los requerimientos.
¿El requerimiento definido

coincide con los objetivos del Sí Se debe hacer una trazabilidad y verificación.
proyecto?
¿Se identificaron los riesgos del Para el caso de San Marcos no se está haciendo una
No
proyecto? identificación detallada de los riesgos del proyecto
¿Se siguió un proceso razonable

Convocatoria, reuniones y la emisión de
en la definición del Sí
documentos con los requerimientos maduros.
requerimiento?
¿El proceso de control de

requerimientos, es adecuado No se está haciendo un “match” para minimizar los
No
para minimizar los riesgos del riesgos del proyecto
proyecto?
¿Durante el proceso de control

Se pacta una reunión para comunicar a los clientes
de requerimientos se ha llevado Sí
los requerimientos acordados.
a cabo un “walktrough”?
Depende de la organización en San Marcos, las

¿La técnica más adecuada para
reuniones con clientes son esenciales para
el relevamiento de requisitos es No
comprender los flujos del proyecto y encontrar
la entrevista?
soluciones óptimas en colaboración con el equipo
La documentación y la obtención de
¿Se crea un documento de
conformidades del cliente son esenciales para
trazabilidad entre el documento
Sí evitar cambios que puedan afectar el alcance, costo
de requisitos y el documento que
y tiempo del proyecto, alineando los cambios con
los elicita?
la definición inicial del proyecto
15
Universidad
de San Marcos
B.6 Métricas
❖ Métrica de Volatilidad de Requerimientos
Definición: Esta métrica mide la frecuencia con la que los requerimientos cambian
durante el proceso de desarrollo.
Objetivo: Evaluar la estabilidad de los requerimientos a lo largo del tiempo.
Significado: Un valor bajo indica una menor volatilidad, lo que es deseable para
evitar cambios constantes.
Fórmula:
(Número de cambios de requerimientos / Número total de requerimientos) * 100
Escala: Se expresa en términos de porcentaje (0% - 100%) donde cuanto más alto sea
el porcentaje en esta escala, mayor será la volatilidad de los requerimientos, lo que
podría dificultar la planificación y el desarrollo del software.
❖ Métrica de Consistencia de Requerimientos
Definición: Esta métrica evalúa la coherencia y la ausencia de conflictos entre los

requerimientos.
Objetivo: Medir la consistencia de los requerimientos en todo el documento.

Significado: Un valor alto indica que los requerimientos no presentan
contradicciones.
Fórmula:
(Número de requerimientos coherentes / Número total de requerimientos) * 100
Escala: Se expresa en términos de porcentaje (0% - 100%) donde cuanto más alto sea
el porcentaje en esta escala, mayor será la coherencia y la ausencia de conflictos entre
los requerimientos, lo que es deseable para asegurar que los requerimientos sean
claros y no generen confusión en el desarrollo del software
B.7 Involucrados
B.7.1 Equipo de ingeniería
❖ Gerente de Proyecto
16
Universidad
de San Marcos
El Gerente de Proyecto es un líder clave en el equipo de ingeniería

encargado de planificar, ejecutar y supervisar el desarrollo de un proyecto. Su
función principal es asegurar que el proyecto se complete dentro del tiempo,
alcance, costo y calidad previamente definidos. Este rol implica la
coordinación de recursos, la comunicación efectiva y la gestión de riesgos.
❖ Grupo de Análisis de Requerimientos

El Grupo de Análisis de Requerimientos es responsable de identificar,
analizar y documentar los requisitos del sistema que el equipo de desarrollo
debe cumplir. Este equipo juega un papel crucial en la etapa inicial del ciclo de
vida del desarrollo de software, ya que se encarga de comprender las
necesidades del cliente y traducirlas en especificaciones claras y precisas.
B.7.2 Equipo de Aseguramiento de calidad de software
❖ Líder de Aseguramiento de Calidad

El Líder de Aseguramiento de Calidad es un rol de liderazgo en el
equipo de aseguramiento de calidad que tiene la responsabilidad de supervisar
y guiar la ejecución de actividades de aseguramiento de calidad a lo largo del
ciclo de vida del desarrollo. Su objetivo es asegurarse de que los productos o
servicios cumplan con los estándares de calidad y satisfagan las expectativas
de los clientes.
❖ Analista de Aseguramiento de Calidad de Software

El Analista de Aseguramiento de Calidad de Software es un
profesional especializado en la evaluación y mejora de la calidad del software.
Su función principal es llevar a cabo pruebas y análisis exhaustivos para
identificar y reportar defectos, asegurando que el software cumple con los
requisitos y está libre de errores críticos.
17
Universidad
de San Marcos
C. Análisis
Contenido
C.1 Objetivo 19
C.2 Entradas 19
C.3 Proceso 19
C.3.1 Analizar la Especificación funcional 19
C.3.2 Conducir una Inspección Formal 20
C.4 Salidas 21
C.5 Lista de Verificación (Checklist) 22
C.6 Métricas 23
C.7 Involucrados 23
C.7.1 Equipo de ingeniería 23
C.7.2 Equipo de Aseguramiento de calidad de software 24
18
Universidad
de San Marcos
C.1 Objetivo
Es proporcionar un marco de trabajo que permita al equipo hacer estimaciones

razonables de recursos, costos y planificación temporal. Estas estimaciones se realizan al
comienzo del proyecto y deben actualizarse regularmente a medida que progresa. Además,
las estimaciones deben definir los escenarios del mejor y peor caso para limitar los resultados
del proyecto.
C.2 Entradas
❖ Documento de visión: Este documento proporciona una descripción general del

sistema a desarrollar, incluyendo sus objetivos, alcance y limitaciones.
❖ Documento de requisitos: Este documento especifica los requisitos funcionales y no

funcionales del sistema.
❖ Documento de arquitectura: Este documento describe la estructura del sistema,

incluyendo sus componentes, interfaces y dependencias.
❖ Documento de diseño: Este documento describe cómo se implementarán los

requisitos del sistema.
❖ Documento de pruebas: Este documento especifica los casos de prueba que se

utilizarán para verificar que el sistema cumpla con sus requisitos.
C.3 Proceso
C.3.1 Analizar la Especificación funcional
Se deben de tener en cuenta 6 pasos o etapas para realizar el análisis.
❖ Comprender el Contexto: El objetivo de esta etapa es comprender el propósito de la

"Especificación Funcional". En este caso, estamos enfocados en la planificación y los
requisitos. Esto es fundamental para asegurar que el proceso de aseguramiento de
calidad esté alineado con los objetivos de la organización.
❖ Lectura Detallada: Realiza una lectura detallada de la "Especificación Funcional"

para comprender completamente su contenido. En este caso, estamos buscando
información relacionada con la planificación y los requisitos, que son fundamentales
en el aseguramiento de calidad, asimismo buscando posibles inconsistencias o
19
Universidad
de San Marcos
ambigüedades en la especificación.
❖ Relacionar con Documentos de Entrada: Conectar la "Especificación Funcional"

con los documentos de entrada mencionados, como el "Documento de Requisitos del
Usuario" y los "Casos de Uso". Con ello nos aseguramos de que la especificación sea
coherente con estos documentos para garantizar la alineación con las necesidades del
usuario.
❖ Verificar la Trazabilidad: Comprobar que los requisitos funcionales en la

especificación estén trazados adecuadamente a los documentos de entrada. Esto
asegura que no falte ningún requisito y que todos estén cubiertos. Así como, factibles
desde una perspectiva técnica. ¿Pueden implementarse de manera realista? ¿Hay
posibles obstáculos técnicos que deban abordarse?
❖ Identificar Dependencias: Identificar cualquier dependencia entre los requisitos

funcionales. Algunos requisitos pueden estar interrelacionados, y es importante
entender estas relaciones para una planificación y ejecución efectivas.
❖ Evaluar el Impacto de Cambios: Considerar cómo los cambios en la especificación

afectarían al proceso de aseguramiento de calidad. Esto es importante para la gestión
de cambios y para comprender las implicaciones de futuras modificaciones.
C.3.2 Conducir una Inspección Formal
Esta práctica es esencial para garantizar que todos los involucrados comprendan y
estén de acuerdo en los requisitos antes de que comience el proceso de aseguramiento de
calidad, es por ello que se desarrollaron en base a las siguientes fases.
❖ Preparación: Programar una reunión formal de inspección con los miembros clave,
como el equipo de desarrollo y el equipo de aseguramiento de calidad.
❖ Revisión Individual: Antes de la reunión, tanto el equipo de desarrollo como el

equipo de aseguramiento de calidad deben de revisar la "Especificación Funcional".
Cada parte debe identificar problemas, preguntas o sugerencias.
❖ Reunión de Inspección: En la reunión, el líder de la inspección formal (representante

del equipo de aseguramiento de calidad) inicia la reunión y presenta una visión
general de los objetivos de la inspección. Luego, se procede a la revisión detallada de
la "Especificación Funcional".
20
Universidad
de San Marcos
❖ Registro de Cambios: Durante la reunión, se registran todos los cambios propuestos

en la "Especificación Funcional". Esto puede incluir adiciones, modificaciones o
aclaraciones.
❖ Aprobación: Ambos equipos deben estar de acuerdo con los cambios propuestos y
aprobar la "Especificación Funcional" revisada antes de continuar con el proceso de
aseguramiento de calidad.
C.4 Salidas
En el proceso de análisis, las salidas esenciales son documentos y registros que

ayudan a comprender y evaluar los requisitos del proyecto, identificar las necesidades del
cliente y establecer la base para el diseño del software. A continuación, se presentan algunas
de las salidas comunes en el proceso de análisis:
❖ Documento de Requisitos del Sistema: Este documento establece los requisitos de

alto nivel del sistema, proporcionando una visión general de los objetivos y
limitaciones. Es fundamental para comprender la dirección del proyecto
❖ Documento de Requisitos del Usuario: Describe de manera detallada las

necesidades y expectativas de los usuarios finales, lo que es esencial para asegurar
que el software satisfaga sus necesidades.
❖ Matriz de Trazabilidad de Requisitos: Este documento rastrea la relación entre los

requisitos del sistema y los requisitos del usuario, lo que garantiza que todos los
requisitos del usuario se traduzcan en requisitos técnicos.
❖ Informe de Análisis de Riesgos: El análisis de riesgos es crítico para identificar y

mitigar los posibles problemas que pueden surgir durante el desarrollo. El informe de
análisis de riesgos proporciona una visión clara de los riesgos y las estrategias para
abordarlos.
❖ Informe de la Inspección: Este informe documenta las inspecciones realizadas

durante el proceso de análisis, lo que incluye la identificación de problemas y las
acciones correctivas necesarias para garantizar la calidad y la integridad de la
documentación y los requisitos analizados.
21
Universidad
de San Marcos
C.5 Lista de Verificación (Checklist)
No existe una metodología universal para

todos los proyectos, se debe adaptar según
¿La metodología más eficiente o útil las circunstancias y necesidades del
No
para desarrollar proyectos es ágil? proyecto. A veces, es necesario combinar
metodologías. Las pruebas se ajustan a la
metodología y al contexto del desarrollo
La participación del usuario es esencial

desde la propuesta de solución hasta la
¿El usuario final ha estado construcción del producto. No se deben
Sí
involucrado en el análisis? asumir sus necesidades y se debe estar
abierto a escuchar y ajustar los módulos
según sus requerimientos reales
La guía de calidad detalla cómo alinear los

requisitos con la calidad del sistema. Se
¿Se utiliza el PMBOK para el sugieren documentos y plantillas de calidad
aseguramiento de la calidad del Sí de software. En metodologías ágiles,
proyecto? herramientas como JIRA se utilizan para dar
visibilidad y gestionar el proyecto de manera
eficiente
La fidelidad a los requerimientos del usuario

¿La retroalimentación del usuario
final es crucial en el diseño de las pantallas
provoca cambios significativos en la
y funcionalidades. Si el usuario no ha sido
forma en que se muestran las Sí
involucrado y surgen diferencias en los
pantallas después de mostrar los
flujos de trabajo, se deben realizar cambios
prototipos?
en el trabajo ya realizado
En proyectos, es común que antes de agregar

nuevas funcionalidades o realizar
¿Se considera algún aspecto de migraciones, se requiera una mejora previa
análisis al abordar requerimientos en el sistema existente. La consideración
Sí
que implican una migración clave es cómo se llevará a cabo esta
tecnológica en el proyecto? migración, lo que implica estimar el trabajo
tanto en la mejora existente como en las
nuevas funciones a desarrollar
22
Universidad
de San Marcos
C.6 Métricas
❖ Eficiencia de Análisis:
Definición: Esta métrica evalúa la eficiencia del proceso de análisis en términos de la

relación entre el tiempo empleado y la calidad de los resultados obtenidos.
Objetivo: Medir cuánto tiempo se requiere para completar el análisis y cuán efectivo
es en términos de identificar requisitos claros y sin ambigüedades.
Fórmula:
(Tiempo empleado en análisis / Calidad de los resultados obtenidos) * 100
Escala: De 0% a 100%, donde un valor alto indica que el proceso de análisis es

eficiente, es decir, se logra una alta calidad de resultados en un período de tiempo
razonable. Un valor bajo puede indicar la necesidad de mejorar la eficiencia del
proceso de análisis.
❖ Complejidad de Requisitos:
Definición: Esta métrica se centra en la complejidad de los requisitos identificados

durante el proceso de análisis.
Objetivo: Evaluar cuántos requisitos son altamente complejos y pueden requerir un

esfuerzo adicional en términos de diseño e implementación.
Fórmula: (Número de requisitos altamente complejos / Número total de requisitos) *

100
Escala: De 0% a 100%, donde un valor alto indica que una proporción significativa
de los requisitos es altamente compleja, lo que puede tener implicaciones en la
planificación y el desarrollo del proyecto. Se debe prestar atención adicional a estos
requisitos para garantizar una implementación exitosa.
C.7 Involucrados
C.7.1 Equipo de ingeniería
❖ Gerente del Proyecto

El Gerente del Proyecto supervisa y coordina todas las actividades del
proyecto, garantizando que se cumplan los objetivos de tiempo, alcance, costo
23
Universidad
de San Marcos
y calidad. Se encarga de la planificación, asignación de recursos y gestión de

riesgos.
❖ Grupo de Análisis de Requerimientos

Este grupo identifica y documenta los requisitos del sistema en
colaboración con los stakeholders. Trabajan estrechamente con los clientes
para traducir necesidades en especificaciones claras y trazables para el equipo
de desarrollo.
❖ Grupo de Análisis Funcional

Este equipo desglosa los requisitos generales en funciones detalladas
del sistema. Colaboran con el Grupo de Análisis de Requerimientos para
asegurar que los requisitos funcionales sean comprensibles y claros para el
equipo de desarrollo.
C.7.2 Equipo de Aseguramiento de calidad de software
❖ Líder de Aseguramiento de Calidad

El Líder de Aseguramiento de Calidad establece estándares, define
estrategias de prueba y supervisa las actividades de aseguramiento de calidad.
Se asegura de que se sigan los procesos y estándares de calidad.
❖ Analistas de Aseguramiento de Calidad de Software Senior y/o

Semisenior
Estos profesionales ejecutan pruebas exhaustivas del software,
identifican defectos y ofrecen orientación técnica al equipo de desarrollo.
Trabajan en estrecha colaboración con el líder de aseguramiento de calidad
para garantizar que el software cumpla con los estándares de calidad y las
expectativas del cliente.
24
Universidad
de San Marcos
D. Diseño
Contenido
D.1 Objetivo 26
D.2 Entradas 26
D.3 Proceso 27
D.3.1 Análisis de Factores 27
D.3.2 Conducción de la Revisión del Diseño 28
D4. Salidas 29
D.5 Lista de Verificación (Checklist) 30
D.6 Métricas 31
D.7 Involucrados 31
D.7.1 Equipo de Ingeniería 31
D.7.2 Equipo de Aseguramiento de la Calidad del Software 32
25
Universidad
de San Marcos
D.1 Objetivo
El objetivo principal del proceso de diseño es establecer los factores que conducen a
un diseño correcto y preciso que cumpla con los requisitos del usuario y los estándares de
calidad de la organización. Para lograr esto, se deben llevar a cabo revisiones de diseño
periódicas y exhaustivas, así como conducir inspecciones de los entregables del diseño. Estas
revisiones e inspecciones permiten identificar posibles desviaciones con respecto a los
requisitos y corregirlas de manera oportuna, garantizando así un diseño sólido y confiable en
todas las etapas del desarrollo del software.
D.2 Entradas
❖ Especificaciones del diseño: Estas especificaciones detallan los aspectos clave del
diseño del sistema, incluyendo sus características, funcionalidades y restricciones.
Proporcionan una visión clara de cómo se estructurará el sistema y cómo cumplirá
con los requisitos del usuario final.
❖ Diagramas de flujo del sistema: Los diagramas de flujo son representaciones

visuales que muestran el flujo de datos, procesos y decisiones dentro del sistema. Son
útiles para comprender la lógica del sistema y las interacciones entre sus diferentes
componentes.
❖ Requerimientos de software y hardware: Estos requisitos establecen las

condiciones necesarias para que el software funcione correctamente, incluyendo los
recursos de hardware y software que deben estar disponibles para el sistema. Esto
puede incluir especificaciones técnicas, capacidades de memoria, velocidad de
procesamiento, entre otros.
❖ Documento de diseño de alto nivel (Lógico): Este documento ofrece una

descripción general y abstracta del diseño del sistema, centrándose en los aspectos
lógicos y funcionales. Proporciona una visión general de la estructura y las
funcionalidades del sistema sin entrar en detalles específicos de implementación.
❖ Documento de diseño de detalle (Físico y lógico): Este documento proporciona

información detallada sobre el diseño del sistema, tanto a nivel físico como lógico.
Incluye especificaciones técnicas precisas, detalles de la arquitectura,
configuraciones, algoritmos utilizados y cualquier otra información relevante para la
implementación del sistema. El diseño físico se refiere a los aspectos relacionados con
hardware, como la disposición de los componentes, mientras que el diseño lógico se
enfoca en la estructura interna del software y su funcionamiento.
26
Universidad
de San Marcos
D.3 Proceso
D.3.1 Análisis de Factores
❖ Controles de integridad de datos: Es importante para garantizar que la información

en el sistema de software sea precisa, confiable y consistente. La integridad de los
datos es esencial para la toma de decisiones precisas y la eficacia del software en la
organización, y su gestión adecuada contribuye a la calidad del proyecto de software.
❖ Controles de integridad de archivos: Es esencial para proteger la confiabilidad y la

calidad de los datos y activos en un proyecto de software. Ayuda a prevenir la
corrupción de archivos, la pérdida de información y los problemas de seguridad, lo
que contribuye al éxito del proyecto y la satisfacción del usuario.
❖ Método para alcanzar el nivel de servicio requerido: Es fundamental para

garantizar que el software cumpla con los estándares de calidad y rendimiento
establecidos en los requisitos del proyecto. La gestión efectiva de estos aspectos
contribuye a la satisfacción del usuario y al éxito del proyecto de software.
❖ Diseño acorde con la metodología establecida: Se utiliza para garantizar que el

software se desarrolle de manera consistente, siguiendo las mejores prácticas y
cumpliendo con los objetivos del proyecto. La elección de la metodología y la
adhesión al diseño son factores críticos para el éxito en la gestión de proyectos de
software.
❖ Diseño acorde con los requerimientos establecidos: Asegura que el software

resultante satisfaga las necesidades de los usuarios y las partes interesadas. La
comprensión clara de los requisitos y su reflejo en el diseño son esenciales para el
éxito del proyecto.
❖ Mantenibilidad del diseño: Sirve para asegurarse de que el software pueda adaptarse
a cambios en los requisitos del usuario, tecnologías emergentes y desafíos de
seguridad a lo largo del tiempo. Un software altamente mantenible es más económico
de gestionar y puede seguir siendo valioso para la organización a lo largo de su ciclo
de vida.
❖ Interfaces de diseño: Es importante tener en cuenta las interfaces para la creación de

un software intuitivo y atractivo que satisfaga las necesidades de los usuarios. Una
interfaz de usuario bien diseñada mejora la experiencia del usuario, lo que a su vez
contribuye al éxito del proyecto de software.
27
Universidad
de San Marcos
❖ Diseño acorde con criterios establecidos: Garantiza que el software cumpla con las
expectativas de calidad y rendimiento definidas en el proyecto. La adhesión a
estándares y criterios contribuye a la consistencia y la calidad del software, lo que a su
vez tiene un impacto positivo en el éxito del proyecto de software
D.3.2 Conducción de la Revisión del Diseño
❖ Asignar tiempos adecuados: Se asegura que la revisión del diseño sea un proceso
exhaustivo y efectivo en la gestión de proyectos de software. La asignación de tiempo
suficiente y la atención adecuada a la revisión del diseño contribuyen a la calidad y la
eficacia del software final.
❖ Documentar los datos de la revisión: Detalla que todas las observaciones,

conclusiones y recomendaciones se capturen adecuadamente, lo que facilita la toma
de decisiones informadas y la mejora continua del diseño y el desarrollo de software.
También proporciona un registro histórico que puede ser valioso en el futuro para el
seguimiento y la trazabilidad de las decisiones tomadas durante el proceso de
revisión.
❖ Revisar los datos con el equipo de proyecto: Facilita que los resultados de la
revisión sean compartidos y comprendidos por todos los involucrados. Esto facilita la
toma de decisiones informadas y la implementación de acciones necesarias para
mejorar el diseño y el desarrollo del software.
❖ Desarrollar recomendaciones de revisión: Las recomendaciones proporcionan una

guía clara para abordar problemas, mejorar el diseño y garantizar que el software
cumpla con los requisitos y las expectativas del proyecto.
❖ Revisar recomendaciones con el equipo de proyecto: La colaboración y la

discusión abierta con el equipo de proyecto y las partes interesadas ayudan a asegurar
que las recomendaciones estén alineadas con los objetivos del proyecto y que se
tomen decisiones informadas sobre su implementación
❖ Preparar un reporte final: El informe final sirve como un registro histórico de la

revisión, proporciona una guía clara para la implementación de recomendaciones y
acciones de seguimiento, y contribuye a la mejora continua del proyecto de software.
28
Universidad
de San Marcos
D4. Salidas
Los documentos de salida esenciales para garantizar que el proceso de diseño se

realice de manera efectiva y que el software resultante sea coherente con los requisitos,
altamente mantenible y cumpla con los estándares de calidad son los siguientes:
❖ Especificaciones de Diseño Aprobadas: Este documento indica que los modelos de

diseño han sido revisados y aprobados por todas las partes interesadas relevantes.
Pueden ser referidas como "Especificaciones de Diseño Aprobadas" para indicar su
estado de aprobación.
❖ Documento de Aprobación de Diseño: Este documento contiene una declaración de

aprobación e incluye las firmas de las partes interesadas clave. También indica la
versión aprobada del diseño y sirve como registro de aprobación para futuras
referencias.
❖ Registro de Cambios y Acciones Correctivas: Si se identifican problemas durante la

revisión de diseño, se pueden registrar como "acciones correctivas" que deben
abordarse antes de la aprobación como un resumen de la inspección. Esto garantiza
que cualquier problema se resuelva adecuadamente antes de avanzar.
29
Universidad
de San Marcos
D.5 Lista de Verificación (Checklist)
Item Cumple Descripción
Inicialmente, se consideró un modelo relacional,

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

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

adquisición de nueva información. Se establece
¿Se realizó la revisión del diseño de la
Sí un cronograma para entregables y
base de datos en el momento 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

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

¿Utilizan métodos, métricas o específicas para el diseño. Generalmente en el
herramientas para evaluar la diseño se busca que las métricas usadas pasen
Sí
usabilidad, accesibilidad y escalabilidad satisfactoriamente las pruebas de calidad. De
en el diseño de software? 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
¿Se evalúa si el patrón de diseño elegido
Sí selecciona el patrón que se adapte a las
es el más adecuado?
necesidades organizacionales o se basa en
arquitecturas de referencia para software similar
30
Universidad
de San Marcos
Aunque se tenga un área de TI, según sea la

¿Se dan los materiales del diseño para cantidad de trabajadores se desarrollará de
Si
la revisión en el ciclo? manera compleja o no, 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
¿Se solucionan los problemas de con el usuario desde la idea plasmada en una
comunicación con el cliente y los Si solicitud para asegurar que se haya revisado y
arquitectos? tenga 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 Hay muchas áreas disponibles para poder
desempeñarse en el ámbito laboral Si acceder, como programadores, analiticos,
actual? aseguradores de calidad, etc.
D.6 Métricas
❖ Métrica de Escalabilidad de Diseño
Definición: Esta métrica evalúa la capacidad del diseño para adaptarse a cambios o
aumentos en la complejidad sin rehacer gran parte del sistema.
Objetivo: Medir la flexibilidad y escalabilidad del diseño.
Significado: Un valor alto indica un diseño que puede adaptarse fácilmente a futuras
modificaciones.
Fórmula: (Puntos de diseño escalables / Total de puntos de diseño) * 100
Escala: En porcentaje de 0% a 100% donde cuanto más alto sea el porcentaje en esta
escala, mayor será la escalabilidad y flexibilidad del diseño, lo que es deseable para
garantizar que el sistema pueda adaptarse a futuras modificaciones sin un esfuerzo
significativo
❖ Métrica de Acoplamiento de Diseño
Definición: Esta métrica evalúa la dependencia y la relación entre los componentes o

módulos en el diseño del software.
31
Universidad
de San Marcos
Objetivo: Medir el grado de acoplamiento, buscando reducir la interdependencia

excesiva entre los componentes.
Significado: Un valor bajo indica un diseño con un bajo acoplamiento, lo que es

deseable para facilitar la modificación y mantenimiento.
Fórmula: (Puntos de acoplamiento / Total de puntos de diseño) * 100
Escala: En porcentaje de 0% al 100% donde cuanto más alto sea el porcentaje en esta
escala, menor será el acoplamiento entre los componentes en el diseño, lo que es
deseable para facilitar la modificación y el mantenimiento del software
D.7 Involucrados
D.7.1 Equipo de Ingeniería
El Equipo de Ingeniería desempeña un papel fundamental en el proceso de

diseño de software al ser responsable de la traducción de los requisitos en soluciones
técnicas concretas. Este equipo se encarga del diseño, desarrollo, arquitectura,
programación y codificación del software, asegurando la cohesión de los
componentes y la corrección de errores a nivel de código, contribuyendo así a la
creación del producto tecnológico.
D.7.2 Equipo de Aseguramiento de la Calidad del Software
El Equipo de Aseguramiento de la Calidad del Software se enfoca en

garantizar que el software sea desarrollado y entregado con la máxima calidad
posible. Sus tareas incluyen la planificación y ejecución de pruebas exhaustivas,
documentación de hallazgos, validación de requisitos y la implementación de
procesos de mejora continua. Este equipo asegura que el software cumpla con los
estándares de calidad y las expectativas del cliente, contribuyendo a la fiabilidad y
funcionalidad del producto final.
32
Universidad
de San Marcos
E. Codificación
Contenido
E.1 Objetivo 34
E.2 Entradas 34
E.3 Proceso 35
E.4 Salidas 36
E.5 Lista de Verificación (Checklist) 37
E.6 Métricas 38
E.7 Involucrados 38
E.7.1 Equipo de Ingeniería 38
E.7.2 Equipo de Aseguramiento de la Calidad del Software 39
33
Universidad
de San Marcos
E.1 Objetivo
En la etapa de codificación, se lleva a cabo la traducción del diseño de software en

código fuente, siendo un proceso crítico en el desarrollo. Su objetivo principal es
implementar de manera eficiente y de alta calidad las funcionalidades definidas. Durante la
codificación, se trabaja en equipo para traducir el diseño en código, optimizando la eficiencia
y el rendimiento. La claridad y mantenibilidad del código son fundamentales, con pruebas
unitarias para identificar errores tempranamente. La calidad del código es esencial, siguiendo
las mejores prácticas y estándares de calidad. La gestión de errores, seguridad y revisiones de
código garantizan la robustez del sistema. La integración continua, el control de versiones y
el cumplimiento de estándares son prácticas clave para una codificación exitosa.
E.2 Entradas
❖ Especificaciones de programas: Estas especificaciones detallan los requisitos y las

funcionalidades específicas que deben cumplir los programas individuales dentro del
sistema. Proporcionan información detallada sobre cómo deben comportarse los
programas, qué entradas deben aceptar y qué salidas deben generar.
❖ Documentación de programas: La documentación de programas ofrece una

descripción detallada de la estructura, el funcionamiento y el propósito de cada
programa en el sistema. Puede incluir detalles sobre los algoritmos utilizados, las
estructuras de datos, las interfaces y cualquier otra información relevante para
entender y modificar el código.
❖ Listado de código: El listado de código es una representación escrita del código

fuente de los programas. Proporciona una visión detallada de la implementación,
incluyendo las instrucciones, las variables, las funciones y otros elementos del código.
Es esencial para revisar, entender y realizar modificaciones en el código.
❖ Programas ejecutables: Los programas ejecutables son versiones compiladas y listas

para ser ejecutadas en el sistema. Estos archivos contienen el código del programa en
un formato que la computadora puede entender y ejecutar. Los programas ejecutables
son esenciales para probar el software y verificar su funcionamiento real en el entorno
previsto.
❖ Diagramas de flujo de los programas: Los diagramas de flujo de los programas son
representaciones visuales que muestran el flujo de control dentro de cada programa.
Estos diagramas ayudan a entender la lógica del programa, mostrando cómo se toman
las decisiones, qué caminos sigue el programa y cómo se procesan los datos. Son
34
Universidad
de San Marcos
útiles para visualizar el comportamiento de los programas de manera clara y

comprensible.
E.3 Proceso
❖ Implementación del control de integridad de información: Es un aspecto crucial

de la gestión de proyectos de software, ya que contribuye a la calidad y la
confiabilidad del sistema, asegura que los datos sean precisos y consistentes, y
minimiza el riesgo de errores costosos y problemas operativos.
❖ Implementación de reglas de autorización: Es esencial para proteger la integridad y

la seguridad de los datos y las operaciones en un proyecto de software, y es un
componente crítico de la gestión de la seguridad de la información en el desarrollo de
software.
❖ Implementación de control de integridad de archivos: Es fundamental para

garantizar la confiabilidad de los datos y archivos en un proyecto de software y
minimizar el riesgo de corrupción, pérdida de información y problemas de seguridad.
Además, contribuye a mantener la calidad y la integridad del software en general.
❖ Implementación de auditorías de rastreo: Ayuda a garantizar la calidad, la

transparencia y la gestión eficiente del proyecto. Permite a los equipos de desarrollo y
a los interesados tener un control adecuado sobre las actividades y los cambios, lo que
contribuye a la toma de decisiones informadas y a la mejora continua del proyecto.
❖ Implementación de procedimientos de seguridad: Se usa para proteger los datos y

sistemas, minimizar los riesgos de seguridad y garantizar que el proyecto cumpla con
estándares de seguridad y regulaciones aplicables. Estos procedimientos deben ser
parte integral de la gestión de proyectos de software desde el inicio y mantenerse a lo
largo de todo el ciclo de vida del proyecto.
❖ Cumplimiento del programa con la metodología a adoptar: Sirve para asegurar la

consistencia, la calidad y la alineación con las mejores prácticas durante todo el ciclo
de vida del proyecto. Esto contribuye a un desarrollo y una entrega exitosos del
software y facilita la colaboración y la comprensión entre los miembros del equipo y
las partes interesadas.
❖ Programa acorde al diseño (Correctitud): Se centra en garantizar que el software

desarrollado refleje con precisión el diseño y cumpla con los requisitos establecidos.
La correctitud es esencial para ofrecer un software confiable y de alta calidad que
satisfaga las necesidades de los usuarios.
35
Universidad
de San Marcos
❖ Mantenimiento del programa: Es fundamental para garantizar que el software siga

siendo valioso y eficaz a lo largo del tiempo. Esto es especialmente importante en
proyectos de software a largo plazo, donde las necesidades y los requisitos pueden
evolucionar con el tiempo. La gestión efectiva del mantenimiento del programa ayuda
a prevenir problemas, mejora la satisfacción del usuario y prolonga la vida útil del
software.
❖ Desarrollo de procedimientos operativos: Este paso implica la creación de

procedimientos operativos detallados que guiarán el proceso de codificación. Estos
procedimientos incluyen pautas específicas sobre cómo abordar ciertos aspectos del
código, como el estilo de codificación, la documentación, la gestión de errores y otros
factores clave.
E.4 Salidas
Estas salidas son esenciales para garantizar que el proceso de codificación se realice
de manera efectiva, que el código sea de alta calidad y que los problemas identificados sean
documentados y abordados adecuadamente. Además, facilitan la transición a las etapas de
pruebas y despliegue del software.
❖ Documentación de las Pruebas Unitarias: Incluye la verificación que las unidades

de código funcionen correctamente. Comentarios en el código, descripciones de
funciones y módulos, y otras explicaciones que faciliten la comprensión del software.
❖ Registro de Gestión de Errores: Documento que registra los errores identificados y

cómo fueron gestionados, incluyendo información sobre cómo se solucionaron, quién
fue el responsable de la corrección, como su gravedad, ubicación en el código y una
descripción de cómo reproducir el problema.
❖ Informes de Seguridad: Si se han identificado problemas de seguridad durante la

codificación, los informes de seguridad documentarán estos problemas y las medidas
tomadas para abordarlos.
❖ Código Fuente Versionado: Se generan registros de versiones específicas del código

fuente para estar bajo control de versiones para mantener un historial de cambios y
facilitar la colaboración en equipo.
36
Universidad
de San Marcos
E.5 Lista de Verificación (Checklist)
La base de datos es MyBatis y JPA para trabajar de manera más

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

¿Se ha determinado un actividades frontend y backend, como también en base de datos.
equipo de desarrollo con En San Marcos tenemos pocos sistemas (19 o más) y como tal
Sí
roles mínimos especializarse en esos dos puntos es bueno pero se necesita a
establecidos? 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
● Replicación en un ambiente de pruebas con una base de
todos los defectos y se No
datos productiva.
han registrado?
● Priorización en ambiente productivo para evitar
interferencias con otros sistemas
¿Utilizan herramientas Uso de Jira para organizar tareas en frentes, seguimiento semanal
para gestionar los y documentación compartida para el pase a producción.
Sí
requisitos u objetivos
cumplidos?
¿Se toma alguna acción Requisitos no implementables requieren reuniones con el área de
con los requisitos que no Sí análisis para llegar a acuerdos y actualizar los artefactos
se pueden implementar? correspondientes
¿Se consideran puntos Enfoque en manuales concisos con imágenes como ayuda visual
importantes en el manual Sí para los usuarios
de usuario?
Hay sistemas heredados que tenemos como legacy, para esos

¿Hubo un proceso de casos le damos mantenimiento y seguimos trabajando con esas
selección de tecnologías y Sí tecnologías. Para nuevas iniciativas, vemos cual se acomoda
frameworks? mejor y darle uso, así como actualizamos en el caso de Roper o
Angular que no se estuvieron usando antes.
37
Universidad
de San Marcos
¿Se consideran métricas Se consideran generalmente las pruebas de carga, los umbrales
Sí
críticas en el desarrollo? de respuesta y un apoyo en la herramienta JMeter.
E.6 Métricas
❖ Métrica de Cobertura de Pruebas de Código
Definición: Esta métrica evalúa la cantidad de código que está cubierto por pruebas
automatizadas.
Objetivo: Medir la calidad y la robustez del código a través de pruebas exhaustivas.
Significado: Un valor alto indica una mayor cobertura de pruebas.
Fórmula: (Líneas de código cubiertas por pruebas / Total de líneas de código) * 100
Escala: 0 al 100
❖ Métrica de Complejidad Ciclomática
Definición: Esta métrica evalúa la complejidad de control del código, lo que ayuda a
identificar partes del código que pueden ser difíciles de entender o mantener.
Objetivo: Medir la complejidad del código y reducir la probabilidad de errores.
Significado: Un valor bajo indica un código con menor complejidad.
Fórmula: Calculada con herramientas de análisis estático, como la fórmula de

McCabe.
Escala: Variable, pero generalmente se busca mantenerla baja.
E.7 Involucrados
E.7.1 Equipo de Ingeniería
❖ Gerente de Proyecto: El gerente de proyecto tiene la responsabilidad de supervisar y

coordinar las actividades de codificación. Su función incluye la gestión de recursos, la
asignación de tareas, el seguimiento del progreso y la comunicación con las partes
interesadas. También asegura que se cumplan los plazos y los estándares de calidad.
38
Universidad
de San Marcos
❖ Grupo de Programación: Este grupo, formado por programadores, desarrolladores y

otros expertos técnicos, se encarga de llevar a cabo la codificación del software.
Siguen los diseños y las especificaciones técnicas proporcionadas en la fase de diseño
para escribir el código fuente del software. Se enfocan en la implementación de
soluciones técnicas, la depuración de código y la optimización del rendimiento.
E.7.2 Equipo de Aseguramiento de la Calidad del Software
❖ Líder de Aseguramiento de la Calidad del Software: El líder de aseguramiento de

la calidad del software juega un papel crucial en la fase de codificación. Su función
principal es establecer estrategias de aseguramiento de calidad para la codificación,
definir criterios de calidad, y supervisar la ejecución de pruebas y revisiones de
código. Asegura que se sigan estándares de codificación y que se cumplan los
requisitos de calidad.
❖ Analistas de Aseguramiento de la Calidad del Software Senior y/o Semi-senior:

Estos profesionales realizan revisiones de código, pruebas de unidad y pruebas de
integración durante la fase de codificación. Su tarea es identificar y reportar defectos,
errores y problemas de calidad en el código. También colaboran con el equipo de
programación para corregir los problemas detectados y asegurar que el software
cumpla con los estándares de calidad establecidos.
39
Universidad
de San Marcos
F. Pruebas del Sistema
Contenido
F.1 Objetivo 41
F.2 Entradas 41
F.3 Proceso 42
F.3.1 Verificar la Construcción de Datos / “Scripts” de Prueba 42
F.3.2 Verificar la Ejecución de la Prueba 42
F.3.3 Verificar el Registro de los Resultados de la Prueba 43
F.4 Salidas 43
F.5 Lista de Verificación (Checklist) 44
F.6 Métricas 45
F.7 Involucrados 45
F.7.1 Equipo de Ingeniería 45
E.7.2 Equipo de Aseguramiento de la Calidad del Software 45
40
Universidad
de San Marcos
F.1 Objetivo
El objetivo principal de las pruebas del sistema es determinar si el software

funcionará correctamente cuando se ejecute en el entorno previsto. Estas pruebas buscan
validar que el software cumple con los requisitos funcionales y no funcionales establecidos,
así como asegurar que no existen defectos críticos que puedan afectar la operación del
sistema en producción. Además, se pretende identificar posibles inconvenientes, errores o
problemas de rendimiento antes de que el software sea implementado, lo que permite tomar
medidas correctivas oportunas y garantizar la calidad del producto final.
F.2 Entradas
❖ Planes de Pruebas: Los planes de pruebas son documentos que describen la

estrategia general para llevar a cabo las pruebas en un sistema de software. Estos
planes incluyen información sobre los objetivos de las pruebas, el alcance, los
recursos necesarios, el cronograma y los criterios de aceptación. Los planes de
pruebas también detallan las diferentes técnicas y enfoques que se utilizarán para
verificar y validar el software.
❖ Pruebas Funcionales y No Funcionales: Las pruebas de software se dividen en

funcionales (verifican si el software hace lo que se espera, como interacciones del
usuario) y no funcionales (evalúan aspectos como el rendimiento y la seguridad).
Estas categorías se utilizan para asegurar que el software cumple tanto con sus
funciones como con requisitos adicionales importantes.
❖ Datos de Prueba: Los datos de prueba son la información que se utiliza para llevar a
cabo las pruebas. Estos datos pueden incluir casos de prueba, entradas específicas,
valores límite, datos de configuración, datos de usuario simulados, etc. Los datos de
prueba se seleccionan cuidadosamente para asegurarse de que abarquen una variedad
de situaciones posibles y se utilicen para verificar el funcionamiento adecuado del
software en diferentes escenarios.
❖ Resultados de las Pruebas: Los resultados de las pruebas son los informes generados
después de ejecutar los casos de prueba. Estos informes muestran si el software ha
superado o no las pruebas. Los resultados incluyen detalles sobre cualquier defecto
encontrado, como descripciones, gravedad y pasos para reproducirlos. Además, se
registran los resultados exitosos, lo que indica que el software ha pasado con éxito las
pruebas especificadas.
41
Universidad
de San Marcos
F.3 Proceso
F.3.1 Verificar la Construcción de Datos / “Scripts” de Prueba
❖ Diseño de archivos de prueba: En este paso, se planifican y crean archivos de

prueba que contienen datos específicos para probar el sistema. Estos archivos pueden
incluir datos de entrada, configuración y cualquier otra información necesaria para
ejecutar pruebas de manera efectiva.
❖ Ingreso de los datos de prueba: Se trata de la acción de ingresar los datos de prueba
en el sistema o la aplicación que se está probando. Esto puede involucrar la carga de
datos desde los archivos de prueba diseñados o la entrada manual de datos.
❖ Análisis de los resultados esperados: Aquí se establecen las expectativas de los

resultados que se deben obtener al ejecutar las pruebas. Se comparan los resultados
reales con los esperados para determinar si el sistema funciona correctamente.
❖ Creación de casos de prueba: Los casos de prueba se elaboran a partir de los datos y
los escenarios de prueba diseñados. Cada caso de prueba describe una serie de pasos o
acciones a seguir, así como los datos de entrada y los resultados esperados. Estos
casos se utilizarán durante la ejecución de las pruebas.
F.3.2 Verificar la Ejecución de la Prueba
❖ Prueba manual, de regresión y funcional: En este paso, se realizan pruebas

manuales para verificar el funcionamiento del sistema de acuerdo con los casos de
prueba establecidos. Esto incluye pruebas funcionales que evalúan las funciones del
sistema y pruebas de regresión que aseguran que las actualizaciones recientes no
hayan introducido nuevos errores.
❖ Prueba de autorización: Esta prueba se centra en verificar que el sistema solo

permite el acceso a usuarios autorizados y que los permisos se apliquen correctamente
de acuerdo con las políticas de seguridad.
❖ Prueba de integridad: En esta etapa, se evalúa si los datos se almacenan y manejan

de manera íntegra y se garantiza que no se produzcan pérdidas o corrupción de datos
durante las operaciones del sistema.
❖ Prueba de seguridad: Esta prueba tiene como objetivo evaluar la resistencia del
sistema frente a posibles amenazas de seguridad, como ataques de hackers, virus o
intentos de intrusión.
42
Universidad
de San Marcos
F.3.3 Verificar el Registro de los Resultados de la Prueba
❖ Verificación del registro de los resultados de la prueba: Se comprueba que se haya

registrado adecuadamente toda la información relacionada con los resultados de las
pruebas. Esto incluye los resultados reales, los errores encontrados, las evidencias de
prueba y cualquier información relevante que sea necesaria para documentar y
analizar las pruebas realizadas.
F.4 Salidas
En el proceso de pruebas del sistema, es crucial contar con salidas que aseguren la
calidad del software y documenten los resultados de las pruebas. Aquí están las salidas clave
para este proceso, incluyendo los elementos que mencionaste:
❖ Planes de Prueba Verificados: Los planes de prueba describen las estrategias y casos
de prueba que se utilizarán para evaluar el sistema. Es importante que estos planes se
verifiquen y aprueben antes de realizar las pruebas. Esto garantiza que las pruebas
estén bien diseñadas y se ajusten a los requisitos del sistema.
❖ Muestra de Transacciones de Prueba Verificadas: Esta salida se refiere a las

transacciones o escenarios de prueba que se han diseñado y verificado para asegurarse
de que funcionen correctamente. Incluye detalles sobre cómo se llevarán a cabo las
pruebas y qué resultados se esperan obtener de estas transacciones.
❖ Desvío de los Resultados Esperados Documentados: Este documento registra

cualquier desvío o discrepancia que se encuentre entre los resultados de las pruebas y
los resultados esperados. Cada desvío se documenta detalladamente, incluyendo la
descripción del problema, la gravedad, la fecha de detección y cualquier información
adicional necesaria para su corrección.
❖ Informe de Pruebas: Este informe detalla las actividades de prueba realizadas,

incluyendo los resultados de las pruebas, la cobertura de las pruebas, los problemas
encontrados y su resolución. Proporciona una visión general de la calidad y el
rendimiento del software probado.
43
Universidad
de San Marcos
F.5 Lista de Verificación (Checklist)
Se dan objetivos claros que se deben cumplir en

¿Todos los pasos fueron realizados como
Sí plazos determinados para no interrumpir el
se especificaron?
desarrollo del proyecto.
Dependiendo del rubro. Es frecuente un

ambiente poco favorable debido a peticiones de
horas extras para culminar objetivos que no se
¿Se estableció un ambiente de prueba
han terminado en el día los atrasos ocasionados
apropiado para realizar la prueba del No
por caídas de servicio, pases de proyectos
software?
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 para esta
Sí previamente para realizar cada etapa del
etapa?
proyecto en un periodo óptimo de tiempo.
Dependiendo de los requerimientos de la

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

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

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

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

evitar los fallos.
Generalmente se gestiona con manejos de

¿Se ha establecido un procedimiento para
backups y se reúnen a los equipos para
asegurar las acciones/ resolución Sí
solucionar los incidentes, dependiendo de la
apropiada de los defectos?
magnitud, se hacen a horas no laborales incluso.
F.6 Métricas
❖ Métrica de Cobertura de Pruebas del Sistema:
Definición: Esta métrica evalúa la proporción del sistema que ha sido probada y
cubierta por casos de prueba.
Objetivo: Medir la exhaustividad de las pruebas y la cobertura del sistema.
Significado: Un valor alto indica una cobertura más completa del sistema.
Fórmula: (Funcionalidad probada / Funcionalidad total del sistema) * 100
Escala: 0 al 100
❖ Métrica de Estabilidad del Sistema:
Definición: Esta métrica evalúa la estabilidad del sistema durante las pruebas,
midiendo la cantidad de veces que se rompe o falla.
Objetivo: Medir la confiabilidad y la estabilidad del sistema.
Significado: Un valor bajo indica una mayor estabilidad del sistema.
Fórmula: (Número de fallos del sistema / Total de ejecuciones de prueba)
Escala: 0 al 100
F.7 Involucrados
F.7.1 Equipo de Ingeniería
45
Universidad
de San Marcos
❖ Gerente de Proyecto: El gerente de proyecto supervisa la planificación y ejecución

de las pruebas del sistema. Se encarga de coordinar recursos, definir plazos y
comunicar los resultados de las pruebas a las partes interesadas.
❖ Representante del Grupo de Análisis de Requerimientos: Este representante

garantiza que las pruebas del sistema se alineen con los requisitos especificados en la
fase de análisis. Colabora en la definición de casos de prueba y en la evaluación de si
el software cumple con los requisitos funcionales y no funcionales.
❖ Representante del Grupo de Diseño: El representante del grupo de diseño asegura

que las pruebas consideren los aspectos de diseño y la arquitectura del software. Se
enfoca en evaluar si la implementación técnica del diseño es correcta y se ajusta a las
especificaciones.
❖ Representante del Grupo de Analistas Desarrolladores: Este representante

colabora en la identificación y resolución de problemas encontrados durante las
pruebas del sistema. Trabaja estrechamente con el grupo de testeo y los analistas de
aseguramiento de la calidad para corregir defectos.
❖ Grupo de Testeo: Los miembros del grupo de testeo son responsables de planificar y
ejecutar las pruebas del sistema. Esto implica la creación de casos de prueba, la
ejecución de pruebas funcionales, de rendimiento, de seguridad y otras pruebas
necesarias. Registran y documentan los resultados de las pruebas y colaboran en la
identificación de defectos.
F.7.2 Equipo de Aseguramiento de la Calidad del Software

la calidad del software tiene un papel crucial en la fase de pruebas del sistema.
Establece estrategias de pruebas, coordina la ejecución de pruebas y asegura que se
cumplan los estándares de calidad. Supervisa el proceso de pruebas y se comunica con
el equipo de ingeniería para resolver problemas y defectos.

Los analistas de calidad senior y semi-senior participan en la planificación y ejecución
de pruebas del sistema. Realizan revisiones exhaustivas de los casos de prueba,
pruebas de rendimiento, pruebas de seguridad y otras pruebas especializadas.
Documentan y reportan defectos, y colaboran en la corrección de problemas para
garantizar que el software cumpla con los estándares de calidad y sea libre de errores.
46
Universidad
de San Marcos
47
Universidad
de San Marcos
G. Instalación
Contenido
G.1 Objetivo 48
G.2 Entradas 48
G.3 Proceso 49
G.3.1 Verificación de la Instalación de Nuevo Software 49
G.3.2 Verificación de la Instalación de Cambios de Software 49
G.3.3 Seguimiento en Producción 50
G.3.4 Documentar los Problemas 50
G.4 Salidas 50
G.5 Lista de Verificación (Checklist) 52
G.6 Métricas 53
G.7 Involucrados 53
G.7.1 Equipo de Ingeniería 53
G.7.2 Equipo de Aseguramiento de la Calidad del Software 54
48
Universidad
de San Marcos
G.1 Objetivo
El objetivo principal del proceso de instalación es realizar una verificación completa

de la fase de instalación para nuevos sistemas y/o cambios de versiones. Esto implica
asegurarse de que la instalación del software se lleva a cabo de manera correcta y sin errores,
cumpliendo con todos los requisitos técnicos y de configuración. Además, se busca garantizar
que el software se encuentre en pleno funcionamiento en el entorno de producción tras la
instalación, evitando interrupciones en las operaciones del sistema. La verificación completa
de la instalación es esencial para asegurar una transición fluida y exitosa hacia la nueva
versión del software o la implementación de un sistema recién adquirido.
G.2 Entradas
❖ Plan de Instalación: Un plan de instalación es un documento que describe la

estrategia y los pasos detallados para instalar el software en un entorno específico.
Incluye información sobre los recursos necesarios, los requisitos del sistema, las
dependencias, y el procedimiento a seguir durante la instalación.
❖ Diagrama de Flujo de la Instalación: Un diagrama de flujo de instalación es una

representación gráfica que muestra la secuencia de pasos necesarios para instalar el
software. Proporciona una visión visual de cómo se realiza la instalación y ayuda a los
encargados a comprender el proceso de manera más clara.
❖ Resultados de la Verificación de Instalaciones Especiales: La verificación de

instalaciones especiales se refiere a la comprobación de condiciones específicas o
configuraciones que son únicas o críticas para el software. Los resultados de esta
verificación indican si se han cumplido las condiciones especiales necesarias para el
funcionamiento correcto del software en un entorno determinado.
❖ Documentación de Pase a Producción: La documentación de pase a producción es

un conjunto de documentos que detallan cómo el software pasa de la etapa de pruebas
e instalación a la etapa de producción. Incluye información sobre los pasos finales, la
aprobación y la transición del software a un entorno de producción.
❖ Instrucciones y Procedimientos para los Nuevos Usuarios: Estas instrucciones y

procedimientos proporcionan orientación a los nuevos usuarios del software sobre
cómo utilizarlo de manera efectiva. Incluyen guías, manuales o tutoriales que explican
las funciones y operaciones del software.
49
Universidad
de San Marcos
❖ Resultado del Proceso de Instalación: Este resultado refleja si el proceso de

instalación se ha completado con éxito o si se han encontrado problemas durante la
instalación. Puede incluir información sobre errores, advertencias y problemas que
deben abordarse antes de que el software sea considerado completamente instalado y
funcional.
G.3 Proceso
G.3.1 Verificación de la Instalación de Nuevo Software
❖ Integridad del sistema/versión anterior asegurado: Antes de instalar el nuevo

software, se debe asegurar la integridad del sistema existente y respaldar la versión
anterior del software, garantizando que se pueda volver a un estado anterior en caso
de problemas.
❖ Recuperación ante fallas de la instalación: Se debe planificar la recuperación en

caso de que la instalación del nuevo software falle. Esto incluye procedimientos de
respaldo y restauración.
❖ Control de acceso durante la instalación: Se deben establecer políticas de control

de acceso para garantizar que solo personal autorizado realice la instalación y que se
sigan las mejores prácticas de seguridad.
❖ Instalación acorde a la metodología: La instalación debe seguir una metodología

específica para garantizar que se realice de manera estandarizada y controlada,
minimizando riesgos y errores.
❖ Instalación en producción de los programas indicados en la fecha asignada: La

instalación de nuevos programas o actualizaciones debe llevarse a cabo en el entorno
de producción de acuerdo con un calendario predeterminado y en un momento
adecuado para minimizar el impacto en las operaciones.
❖ Puesta a disposición de instrucciones de instalación: Se deben proporcionar

instrucciones detalladas de instalación a los equipos encargados de llevar a cabo el
proceso.
❖ Procedimientos operativos: Los procedimientos operativos, como la configuración y

ajuste del software, deben seguirse después de la instalación para asegurar que el
sistema esté listo para su uso en producción.
G.3.2 Verificación de la Instalación de Cambios de Software
50
Universidad
de San Marcos
❖ Poner a la aplicación modificada en producción: Se verifica que la aplicación

modificada se instale en producción siguiendo procedimientos similares a la
instalación de nuevo software.
❖ Evaluar la eficiencia de los cambios: Después de la instalación de los cambios, se

evalúa la eficiencia y la efectividad de las modificaciones para asegurarse de que
cumplan con los objetivos previstos.
❖ Monitorear la exactitud de los cambios: Se establece un seguimiento para

garantizar que los cambios no introduzcan errores o problemas inesperados en el
sistema.
❖ Mantener actualizadas con las últimas versiones disponibles, los ambientes de

prueba y producción: Se debe mantener actualizado el entorno de prueba y
producción con las últimas versiones disponibles de software y cambios.
G.3.3 Seguimiento en Producción
❖ Monitoreo de las salidas del aplicativo: Se establece un monitoreo continuo de las

salidas del aplicativo en producción para detectar problemas o anomalías que puedan
surgir después de la instalación de una nueva versión.
❖ Documentación de indicios: Cualquier indicio de problemas detectados durante el

monitoreo se debe documentar utilizando un formulario o sistema de registro
específico.
G.3.4 Documentar los Problemas
❖ Documentación de problemas detectados: Cualquier problema detectado durante el

monitoreo debe ser documentado de manera detallada, incluyendo su descripción,
gravedad y contexto.
❖ Evaluación del riesgo asociado: Cada problema documentado debe evaluarse en

términos de su impacto en el sistema y la organización. Esto ayuda a priorizar la
resolución de problemas.
G.4 Salidas
En el proceso de instalación de software, es fundamental garantizar que la implementación se

realice de manera efectiva y que se monitoreen los cambios para evitar problemas. Aquí están
las salidas clave para el proceso de instalación, incluyendo los informes solicitados:
51
Universidad
de San Marcos
❖ Reporte de recuperación ante fallas:Este reporte describe las estrategias y

procedimientos de recuperación que se deben seguir en caso de que ocurran fallas
durante o después de la instalación del software. Puede incluir información sobre
copias de seguridad, procedimientos de restauración y cómo minimizar el tiempo de
inactividad en caso de problemas críticos.
❖ Reporte de notificación de monitoreo de cambios de software: Este reporte detalla

cómo se llevará a cabo el monitoreo de cambios de software. Puede incluir
información sobre herramientas de monitoreo, frecuencia de revisiones y
notificaciones a las partes interesadas cuando se realicen cambios en el software o su
configuración.
❖ Reporte de problemas causados por cambios de software:Este reporte documenta

los problemas que puedan surgir como resultado de cambios en el software. Incluye
detalles sobre los problemas detectados, su impacto en el sistema y las acciones
correctivas que se tomarán para abordarlos. También puede incluir recomendaciones
para evitar problemas similares en el futuro.
❖ Plan de implementación: Este documento describe detalladamente el plan de

implementación del software, incluyendo la secuencia de acciones, los recursos
necesarios, el cronograma de implementación y los procedimientos de validación y
prueba. Es fundamental para asegurarse de que la instalación se realice de manera
ordenada y efectiva.
❖ Informe de verificación y validación de la instalación: Este informe documenta las

actividades de verificación y validación realizadas durante la instalación del software.
Incluye detalles sobre cómo se comprobó que el software se instaló correctamente y
que cumple con los requisitos especificados. Este informe es esencial para garantizar
la calidad y la conformidad con los estándares.
52
Universidad
de San Marcos
G.5 Lista de Verificación (Checklist)
En desarrollo, los nuevos miembros del equipo suelen

depender de los más experimentados hasta que adquieren
¿Puede un programador
confianza en la aplicación. En sistemas antiguos (no
cometer errores importantes
Sí DevOps), es esencial que no haya cajas negras, lo que
en un programa web o de
significa que 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

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

correos o sistemas de seguimiento, mientras que en un
¿Se sigue un procedimiento
entorno DevOps, las comunicaciones se gestionan de
para monitorear los cambios Sí
manera más eficiente a través de herramientas
en el despliegue del sistema?
especializadas. Se describen diferencias entre ambas
prácticas
¿Se abordan los riesgos no Los riesgos altos y medios deben abordarse antes de
corregidos de alguna Sí avanzar a la siguiente etapa, ya que pueden ser bloqueantes.
manera? Los riesgos bajos pueden permitirse en ciertos casos
La organización puede no autorizar el despliegue si se

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

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

¿Existe un papel de
de la documentación y el monitoreo constante durante el
monitoreo continuo y Sí
proceso de despliegue. El equipo de desarrollo está presente
contribuye al sistema?
hasta que el usuario confirma que todo está en orden
G.6 Métricas
❖ Métrica de Disponibilidad del Sistema:
Definición: Esta métrica evalúa el tiempo en el que el sistema está disponible y

operativo después de la implementación.
Objetivo: Medir la disponibilidad del sistema para los usuarios finales.
Significado: Un valor alto indica una alta disponibilidad del sistema.
Fórmula: (Tiempo de disponibilidad del sistema / Tiempo total después de la

implementación) * 100
Escala: 0 al 100
❖ Métrica de Consumo de Recursos durante la Implementación:
Definición: Esta métrica evalúa el uso de recursos (CPU, memoria, ancho de banda,
etc.) durante la implementación o el despliegue.
Objetivo: Medir la eficiencia en el uso de recursos durante el proceso.
Significado: Un valor bajo indica un uso eficiente de recursos.
Fórmula: Puede variar según los recursos medidos.
Sistema de unidades: Porcentaje de uso de recursos.
G.7 Involucrados
G.7.1 Equipo de Ingeniería
❖ Gerente de Proyecto: El gerente de proyecto supervisa la planificación y ejecución

de la instalación de software. Se encarga de coordinar los recursos necesarios,
54
Universidad
de San Marcos
establecer plazos y asegurarse de que la instalación se realice de acuerdo con los

requisitos y las expectativas del cliente.
❖ Grupo de Instalación de Software: Este grupo tiene la responsabilidad de llevar a

cabo la instalación del software en el entorno del cliente o en los servidores
designados. Esto implica la configuración de los componentes del software, la carga
de datos y cualquier otra tarea necesaria para que el software funcione correctamente.
❖ Grupo de Operaciones: El grupo de operaciones se encarga de gestionar la

infraestructura de hardware y software en la que se instalará el software. Aseguran
que los servidores estén disponibles y configurados adecuadamente, y que el entorno
operativo cumpla con los requisitos técnicos necesarios para la instalación y
operación del software.
G.7.2 Equipo de Aseguramiento de la Calidad del Software

la calidad del software desempeña un papel importante en la fase de instalación al
coordinar la verificación de que el proceso de instalación se realice de acuerdo con los
estándares y requisitos de calidad establecidos. Supervisa la ejecución de pruebas de
instalación y verifica que el software se haya configurado adecuadamente.

Los analistas de calidad participan en la ejecución de pruebas específicas relacionadas
con la instalación. Verifican que el proceso de instalación sea exitoso y que el
software funcione correctamente en el entorno objetivo. Documentan y reportan
cualquier problema o defecto que pueda surgir durante la instalación.
55

Grupo 3 - Plan de Aseguramiento - Proyecto Final

Cargado por

Información del documento

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

Grupo 3 - Plan de Aseguramiento - Proyecto Final

Cargado por

Copyright:

Formatos disponibles

Universidad Nacional Mayor de San Marcos.

Facultad de Ingeniería de Sistemas e Informática.

F. Pruebas del Sistema 40

A.3.1. Verificación de la Estimación del Proyecto 4

A.3.2. Verificación del Estado del Proyecto 4

A.5. Lista de Verificación (Checklist) 7

A.7.1 Equipo de Ingeniería 9

A.7.2 Equipo de Aseguramiento de calidad 9

En este punto, se define el propósito o los objetivos específicos que se pretenden

La identificación y gestión de las entradas es esencial para planificar y llevar a cabo el

❖ Documentación: Puede incluir documentos relacionados con estándares de calidad,

❖ Datos históricos: La información sobre proyectos anteriores o resultados de calidad

❖ Planes y programas: La planificación también puede incluir programas de trabajo,

❖ Contexto: Es importante tener en cuenta el contexto en el que se realizará el

A.3.1. Verificación de la Estimación del Proyecto

La verificación de la estimación del proyecto implica revisar y validar las

❖ Estimación de tiempo: Se verifica si el tiempo estimado para completar las

❖ Estimación de recursos: Se verifica si los recursos necesarios, como personal,

❖ Estimación de costos: Se verifica si los costos asociados al proyecto, incluyendo

❖ Contingencias y riesgos: Se revisan las estimaciones a la luz de posibles riesgos y

A.3.2. Verificación del Estado del Proyecto

❖ Avance del cronograma: Se verifica si el proyecto se está desarrollando de acuerdo

❖ Presupuesto: Se verifica si el gasto del proyecto se encuentra dentro de los límites

con las estimaciones y la identificación temprana de posibles desviaciones

❖ Riesgos y problemas: Se verifica si se están gestionando adecuadamente los riesgos

❖ Medición del progreso: Las salidas permiten medir el progreso de un proyecto o

❖ Comunicación: Las salidas proporcionan una forma de comunicar los resultados y

❖ Documentación: Las salidas a menudo incluyen documentos y registros que registran

Las salidas pueden variar según el tipo de proyecto o proceso. En un proyecto de

En resumen, las salidas representan los resultados tangibles e intangibles de un

A.5. Lista de Verificación (Checklist)

Ítem Cumple Descripción

Nosotros para poder desarrollar el software

El plan de proyecto contempla costo, equipo,

La estimación es anual, donde se

Se ha desarrollado una metodología

La estimación está relacionada al tiempo, en

¿La estimación efectuada es El plan es a futuro, por lo tanto no siempre

Existe un solo entregable que se remite de

❖ Capacidad de Carga de Trabajo

Definición: Se refiere a la medida de la capacidad del software para manejar

Objetivo: Evaluar si el software es capaz de manejar la carga de trabajo necesaria sin

Significado: Es fundamental, ya que un software que no puede manejar la cantidad de

Escala: Se expresa en términos de porcentaje, donde el 100% indicaría que el

❖ Productividad del Equipo de Desarrollo

Definición: Mide la eficiencia del equipo en la creación de software. Se expresa en

Objetivo: Evaluar la eficiencia del equipo de desarrollo en la etapa de planificación.

Significado: Es esencial para la planificación, ya que proporciona una medida

Escala: Se expresa en términos de porcentaje, donde 0% representa la falta de trabajo

❖ Jefe del Proyecto:

A.7.2 Equipo de Aseguramiento de calidad

❖ Líder de Aseguramiento de la Calidad del Software:

B.3.1 Realizar un análisis de factores a verificar 12

B.3.2 Conducir un “walkthrough” de requerimientos 13

B.5 Lista de Verificación (Checklist) 15

B.7.1 Equipo de ingeniería 16

B.7.2 Equipo de Aseguramiento de calidad de software 17

El objetivo principal de este proceso es asegurar que el software desarrollado cumple

❖ Documento de Requisitos del Usuario (URD): Este documento es fundamental, ya

❖ Historias de Usuario: Si se está utilizando una metodología ágil, las historias de

❖ Documentación de Casos de Prueba: Los casos de prueba son vitales para

❖ Documentación de Aprobación del Usuario: La aprobación del usuario es un hito

B.3.1 Realizar un análisis de factores a verificar