Este documento presenta un resumen de 3 oraciones o menos: El documento describe un plan de aseguramiento de calidad de software que incluye definiciones de SQA, un ejercicio de plan de aseguramiento con objetivos y alcance, y detalles sobre control de cambios, especificaciones de requerimientos y descripción del diseño de software siguiendo modelos estandarizados. El plan busca asegurar que el software cumpla los requerimientos establecidos y mejore la calidad durante el desarrollo.

1. 1
UNIVERSIDAD AUTÓNOMA DE NUEVO LEÓN
FACULTAD DE INGENIERÍA MECÁNICA Y ELÉCTRICA
CALIDAD EN EL SOFTWARE
Actividad Fundamental #3
Investigar en diferentes fuentes de información, la definición y propósito
del SQA, elaborar un ejercicio del plan de aseguramiento; definir métodos
de gestión de cambio y dar seguimiento de los datos de calidad
Nombre:
Carrera: IAS Matricula: 1818561
Grupo: 007 Hora: N4
Docente: Ing. Luis Esteban Vega Gómez
Semestre: Enero - junio2022
A 26 de mayo del 2022, San Nicolás de los Garza, Nuevo León.

2. 2
Introducción
Sabemos que en la actualidad las empresas y organizaciones se ven enfrentadas a
competencias de nivel mundial, en donde la calidad de sus productos y servicios se convierte
en un importante punto diferenciador, pues la mayoría de los productos o servicios que
poseen certificados de calidad son preferidos por los usuarios y compradores ya que generan
y trasmiten seguridad y confianza.
Para poder llevar a cabo el aseguramiento y certificación de la calidad de los productos y
servicios que se desarrollan, se lleva a cabo el Aseguramiento de la Calidad del Software, o
conocido en inglés como Software Quality Assurance (SQA), es decir, un modelo sistemático
y planeado de todas las acciones necesarias para proveer la confianza adecuada, según los
requerimientos técnicos establecidos, de cada producto e ítem del proyecto.
Con el objetivo de saber más de este tema, nos vimos en la necesidad de realizar una
investigación exhaustiva sobre el SQA, abarcando diversas definiciones, el propósito de este,
así como la elaboración de un ejercicio del plan de aseguramiento, por último, se define
diversos métodos de gestión de cambio y como se puede dar seguimiento a los datos de
calidad.
La implementación de una disciplina de SQA tiene como principal objetivo aumentar la
calidad de los entregables durante todo el proceso de desarrollo. Muchos requerimientos de
calidad, sobre todo aquellos que tienen que ver con la performance, la usabilidad, la carga,
la disponibilidad, etc. pueden ser tratados como riesgos. Es decir que, el hecho de que uno
de ellos no se cumpla, implica un riesgo. Entonces, al asegurar la calidad del software durante
su proceso, se disminuyen los riesgos asociados, aumentando la predictibilidad del desarrollo
de software. Esto trae aparejado una serie de beneficios de variada visibilidad.
Definición
Para empezar con el tema debemos conocer cuando hablamos de aseguramiento de la calidad
del software, puesto que es la parte principal para el desarrollo de un software en buena
calidad, entonces podemos describir su concepto en varias clasificaciones según autores:

3. 3
Dentro del primer concepto se define el SQA como un “conjuntode actividades planificadas
y sistemáticas, cuyo primer objetivo es evaluar la calidad y la adherencia de los productos
de software a los estándares, procesos y procedimientos”.
Esto nos dice que el SQA permite proveer de una visibilidad adecuada del proceso utilizado
los productos construidos mediante acciones planificadas y sistemáticas. Estas acciones
permiten asegurar la calidad de dichos procesos y productos.
Otro concepto nos dice que el aseguramiento de calidad de software como tal “se compone
por un conjunto de actividades planificadas y sistematizadas que aseguran que el proceso
de desarrollo de un software sea evaluado con respecto a su calidad, la correcta
implementación de procesos, requerimientos y estándares de desarrollo”.
Para de esta manera garantizarle al cliente un producto desarrollado bajo estándares óptimos
de calidad y ajustados totalmente a sus necesidades empresariales y personales.
Los procesos mencionados incluyen todas las actividades involucradas en el diseño,
codificación, pruebas y mantenimiento; Los productos incluyen software, datos asociados,
documentación, y toda la documentación para soporte y reportes.
El tercer concepto desde el punto de vista de la evidencia definido por el Instituto de
Ingenieros Eléctricos y Electrónicos (IEEE), dice que es “Una guía planificada y sistemática
de todas las acciones necesarias para proveer la evidencia adecuada de que un producto
cumple los requerimientos técnicos establecidos”. Refiriéndose a que se debe contar con un
plan de aseguramiento de la calidad software.
Un concepto definido por Daniel Galin dice que el SQA es “Un conjunto sistemático y
planificado de acciones necesarias para proveer la evidencia adecuada de que el
proceso de desarrollo o mantenimiento de un sistema de software cumple los
requerimientos técnicos funcionales también como los requerimientos gerenciales”.
Esto con el fin de que se cumpla con la planificación y operar dentro del presupuesto
confinado.

4. 4
Desde el punto de vista del aseguramiento, Don Refier define al SQA como “Un sistema de
métodos y procedimientos usados para asegurar que el producto de software alcanza sus
requerimientos”.
Por otro lado, Desde el punto de vista de la capacidad de uso, Schulmayer Y Mcmanus
definen el SQA como “Las actividades sistemáticas que proveen evidencia de la capacidad
o disponibilidad de uso del producto del software total”.
¿Para qué sirve?
Un producto de software tiene una gran probabilidad de que pueda tener ciertas fallas si no
se realizaron las pruebas que pudieran evidenciar estos errores. Esta situación podría
provocar el fracaso del producto e impactar negativamente en la toda la empresa o compañía
que tiene la propiedad de este.
No parece razonable que la imagen de toda la organización se vea afectada por el resultado
fallido de un producto de software. Teniendo además presente que existen herramientas que
permiten evitar y corregir los errores que se puedan ejecutar. De esta manera, se podría
entregar un producto que cumpla con los requerimientos y necesidades de los distintos
usuarios. Surge, por lo tanto, la necesidad de asegurar la calidad del producto.
Aquí es donde toma importancia el desarrollo de un plan de SQA, pues este servirá para que
un producto de software cumpla con los requerimientos y necesidades que tiene el cliente. El
resultado final se encontrará certificado y asegurando la calidad de éste.
Además, va a permitir que se puedan planificar las actividades de aseguramiento de la
calidad, revisar y auditar objetivamente los productos y las actividades. Proporciona además
los resultados de estas revisiones o auditorias informando a la dirección del proyecto y
aumentar la calidad de los entregables durante todo el proceso de desarrollo.
Por medio de estos elementos, el QA va a contribuir, en simples palabras, a obtener un
producto de software de calidad, certificado y probado, que cumpla con requisitos que son
necesarios para dar respuesta a las necesidades de los usuarios. La realización de un plan de
aseguramiento de la calidad evitará que la empresa se exponga a situaciones de riesgo.

5. 5
Ejercicio plan de aseguramiento
PROPOSITO
El propósito de este plan es especificar las actividades que se realizarán para asegurar la
calidad del software a construir. En él se detalla el producto que se va a revisar y los
estándares, normas o métodos a aplicar, los métodos y procedimientos que se utilizarán
para revisar que la elaboración del producto se realice como lo establece el modelo de ciclo
de vida del proyecto, y procedimientos para informar a los responsables del producto los
defectos encontrados y realizar un seguimiento de dichos defectos hasta su corrección.
OBJETIVO
Definir un conjunto de normas y actividades con el fin de asegurar la calidad en el desarrollo
de software.
DESCRIPCIÓN
Calidad del software es el cumplimiento con los requisitos explícitamente establecidos y
documentados, la concordancia con los estándares de desarrollo aplicados y la agregación de
requisitos implícitos que se espera de todo producto hecho por profesionales. A través de la
implantación del SQAP se pretende cumplir con los elementos de calidad de software, los
cuales son:
 Correcto
 Eficiente
 Fiable
 Facilidad de uso
 Facilidad de mantenimiento
 Seguridad e integridad
 Portabilidad
Se pretende la aplicación del SQAP para cualquier proyecto de software a desarrollarse
por la empresa.

6. 6
ALCANCE
Este documento presenta enfoques a seguir de manera de asegurar al cliente la calidad
deseada. El alcance de este plan cubre todas las actividades involucradas en el proceso de
desarrollo dejando de lado la etapa de mantenimiento, la cual no será parte de este. La meta
del plan de aseguramiento de la calidad es verificar que todo software y documentación
liberados cumplan con todos los requerimientos técnicos establecidos. El SQAP cubre las
fases del ciclo de vida de desarrollo de software. Ciclo de Vida de Desarrollo de Software
XP (Programación Extrema)
FASES DE XP:
1ª Fase: Planificación del proyecto.
2ª Fase: Diseño.
3ª Fase: Codificación.
4ª Fase: Pruebas.
TAREAS
La relación de tareas asociadas con el ciclo de vida de desarrollo de software (se encuentra
basadas en las 4 fases de XP) y las actividades de la SQA son las siguientes, las cuales se
ejecutarán durante el desarrollo del producto de software:

7. 7
Las actividades de SQA definidas en el modelo de proceso son:
Control De Cambio
El control de cambio del SQAP, será realizado utilizando versiones evolutivas así por
ejemplo al presente SQAP, se denomina como la versión 1.0, los siguientes puntos
describen el criterio a seguir para la asignación de versión a las modificaciones del SQAP.
1. Si los cambios solo afectan a secciones especificas del SQAP, y las mismas no
modifican la línea base del SQAP, la versión asignada será la suma de más
0.1, a la versión actual, los cambios se realizan insertando y/o eliminando hojas en
le SQAP vigente.

8. 8
2. Si los cambios son significativos la versión asignada será la suma de cualquier valor
entre [0.1,0.2, ...1.1,1.2,...., 1.9,2,2.1] para alcanzar el próximo número entero, a
la versión actual del SQAP y se imprimirá completamente el nuevo SQAP.
3. Si se quiere con frecuencia el punto (1), y no se imprimió completamente el
SQAP modificado ya varias veces, entonces para contar con un SQAP
consistente y mantenible se debe imprimir completamente el plan, con todas
las modificaciones realizadas previamente, para la asignación de versión se utilizará
el criterio descrito en el punto 2
CUANDO HACER MODIFICACIONES
Las modificaciones al SQAP serán realizadas cuando se presenten las siguientes situaciones:
 En las relaciones y evaluaciones establecidas en este Plan.
 Otras situaciones pueden ser:
 Surgen nuevos cambios necesarios en los requerimientos.
 Se detectan problemas que modifican la línea base del SQAP, en alguna de
las fases dela Implementación del SQAP.
 Incumplimiento con alguna de las secciones establecidas en el SQAP.
 Por observación de cualquiera de las organizaciones
IMPLANTACIÓN DE MODIFICACIONES
Las modificaciones al SQAP, se harán en función al problema presentado de la siguiente
manera:
 Detectar uno de los puntos especificados.
 Realizar un análisis del problema.
 Realizar reuniones técnicas con las áreas involucradas en la modificación del SQAP,
estas áreas además de exponer problemas, darán recomendaciones para la
modificación correspondiente.
 Hacer la modificación.
 Implementar la modificación correspondiente.
 Una vez finalizada la implementación se evaluará si fue correcta la modificación.

9. 9
 Promulgar la nueva versión del SQAP.
La ERS deberá describir claramente y de forma precisa cada uno de los requerimientos del
software, tal como: funciones, rendimiento, restricciones de diseño y atributos.
MODELO A USAR PARA EL CONTENIDO DEL ERS
1. INTRODUCION
1.1.1. Objetivo
1.1.2. Alcance
1.1.3. Definiciones, acrónimos y abreviaciones
1.1.4. Referencias
1.1.5. Revisión
2. DESCRIPCION GENERAL
2.1 Perspectiva del producto
2.2 Funciones del producto
2.3 Características de los usuarios
2.4 Restricciones generales
2.5 Asunciones y dependencias
3. ESPECIFICACION DE REQUERIMIENTOS
3.1 Requerimiento Funcional
3.1.1. Introducción
3.1.2. Entradas
3.1.3. Procesos
3.1.4. Salidas
3.1.5. Interfaces externas
3.1.5.1. Interfaces del usuario
3.1.5.2. Interfaces del hardware
3.1.5.3. Interfaces del software
3.1.6 Requerimientos de rendimiento
3.1.7 Representación del diseño
3.1.8 Cumplimientos con estándares
3.1.9 Limitaciones del hardware

10. 10
3.1.10 Atributos
3.1.10.1. Disponibilidad
3.1.10.2. Seguridad
3.1.10.3. Mantenibilidad
3.1.10.4. Transferencia / Conversión
3.1.10.5 Prevenciones
3.1.11 Otros requerimientos
3.1.11.1. Base de datos
3.1.11.2. Operaciones
3.1.11.3. Adaptaciones
DESCRIPCIÓN DEL DISEÑO DEL SOFTWARE (DDS)
La generación y documentación de la descripción del diseño de Software se basa en el
estándar ANSI / IEEE – Std 1016 “RECOMMENDED PRACTICE FOR SOFTWARE
DESCRIPTIONS”

11. 11
MODELO A USAR PARA EL CONTENIDO DEL DDS
1. INTRODUCION
1.1. Objetivo
1.2. Alcance
1.3. Definiciones, acrónimos y abreviaciones
2. REFERENCIAS
3. DESCRIPCION DE DESCOMPOSICION
3.1. Descomposición de módulo
3.1.1. Descripción del módulo 1
3.1.n. Descripción del módulo n
3.2. Descomposición de procesos concurrentes
3.2.1. Descripción del proceso 1
3.2.n. Descripción del proceso n
3.3. Descomposición de datos
3.3.1. Descripción de la entidad de datos 1
3.3.n. Descripción de la entidad de datos n
4. DESCRIPCION DE DEPENDENCIA
4.1.Dependencia entre módulos
4.2.Dependencia entre procesos
4.3.Dependencia entre datos
5. DESCRIPCION DE INTERFACES
5.1. Interfaces de módulo
5.1.1. Descripción del módulo 1
5.1.n. Descripción del módulo n
5.2 Interfaces de procesos
5.2.1. Descripción del proceso 1
5.2.n. Descripción del proceso n
6. DISEÑO DETALLADO
6.1. Diseño detallado del módulo
6.1.1. Detalle del módulo 1
6.1.n. Detalle del módulo n

12. 12
6.2. Diseño detallado de datos
6.2.1. Detalle de entidad de datos 1
6.2.2. Detalle de entidad de datos 2
PLAN DE VERIFICACIÓN Y VALIDACIÓN
La generación y documentación de la descripción del Plan de Verificación y Validación (V
& V) es la siguiente:
MODELO A USAR PARA EL CONTENIDO DEL V & V
1. OBJETIVO
2. ALCANCE
3. DEFINICIONES, ACRONIMOS Y ABREVIACIONES
4. ORGANIZACIÓN RESPONSABLES
5. CICLO DE VIDA DE VERIFICACION Y VALIDACION
La organización responsable por las tareas de verificación y validación del software es la
organización de SQA comandada por la organización del consultor, la cual interactúa con la
organización de desarrollo para alcanzar los objetivos del plan. En casos necesarios de
conflictos extremos entre el consultor y el desarrollador se recurrirá al cliente.
CICLO DE VIDA DE VERIFICACIÓN Y VALIDACIÓN
El plan se basa en el siguiente ciclo de vida del software:
 Fase de concepto
 Fase de requerimientos
 Fase de diseño
 Fase de implementación
 Fase de prueba
 Fase de instalación y prueba
 Fase de operación y mantenimiento

13. 13

14. 14

15. 15
INFORMACIÓN DE VERIFICACIÓN Y VALIDACIÓN
El formato para la documentación de los resultados de la implementación del plan de
verificación y validación del software (V & V) es la siguiente:
REPORTE SUMARIO DE FASE V&V

16. 16
REPORTE DE ANOMALÍAS

17. 17
REPORTE FINAL V&V

18. 18
DOCUMENTACIÓN DE USUARIO
Esta descripción de documentación de usuario (UD) se basa en el estándar ANSI / IEEE –
Std 1036 “STANDARD FOR SOFTWARE USER DOCUMENTATION”.
La información especificada debe ser incluida en la documentación del usuario, esta
documentación de usuario comprenderá de un conjunto. En cada documento se debe tomar
en cuenta y describir los siguientes puntos.
Los documentos de usuario serán presentados en dos modos: instruccional y de referencia.
Los usuarios del software utilizarán los documentos ya sea para aprender acerca del software
(modo instruccional) o para refrescar su memoria acerca del software (modo de referencia).
Modo Instruccional
Un modo instruccional de documento debe:
 Proveer el ambiente y la información necesaria para entender el sistema.
 Proveer la información necesaria para aprender lo que puede hacer con el software y
como lo puede usar.
 Proveer ejemplos para reforzar el proceso de aprendizaje.
Modo de Referencia
Un documento de modo de referencia debe:
 Organizar y proveer información necesaria.
 Facilitar accesos aleatorios a la información.
Los documentos de modo de referencia que debe ser incluido son:
a. Manual de comandos
b. Manual de mensajes de error.
c. Manual de llamadas de programas.
d. Guía de referencia rápida.
e. Manual de Herramientas del software.
f. Manual de utilitarios.

19. 19
CONCLUSIÓN GRUPAL
SQA es un conjunto de actividades que tienen como objetivo bajar el costo de desarrollo
alcanzando los parámetros de calidad establecidos. Es factible alcanzar calidades y costos
establecidos, pero es necesario saber, que no es posible injertar calidad deseada al final del
proceso de desarrollo, sino que se debe crear a lo largo de todo el proceso. Mientras antes
se comiencen con las actividades de SQA, mayores serán los beneficios.
Referencias
 R., C.(2019, 12 junio). SQA: qué es, para que sirve y sus beneficios para el desarrollo
de software. Atica Ingeniería. Recuperado 19 de mayo de 2022, de
https://aticaingenieria.cl/sqa-que-es-para-que-sirve-y-sus-beneficios/
 IEEE Standard Glossary of Software Engineering Terminology, IEEE Std 610.12-
1990, 1990.
 Galin, D., Software Quality Assurance – From Theory to Implementation, Pearson
Education Limited, 2004.
 Reifer, D., State of the Art in Software Quality Management, Reifer Consultants,
1985.
 Schulmeyer, G. G. and McManus, J. I., eds. Handbook of Software Quality
Assurance, 2nd ed, Van Nostrand Rheinhold, 1992.
 Descubre los beneficios del Aseguramiento de calidad de software (SQA). (2020, 24
abril). Globalbit. Recuperado 19 de mayo de 2022, de
https://www.globalbit.co/2020/04/25/descubre-los-beneficios-del-aseguramiento-
de-calidad-de-software-sqa/