02 Modelos y Control de Calidad PDF

MODELOS Y CONTROL DE CALIDAD
SEMANA 2
Aseguramiento de la
calidad del software
(SQA)
Todos los derechos de autor son de la exclusiva propiedad de IACC o de los otorgantes de sus licencias. No está
permitido copiar, reproducir, reeditar, descargar, publicar, emitir, difundir, poner a disposición del público ni 1
ESTE
utilizarDOCUMENTO
los contenidos paraCONTIENE LAdeSEMANA
fines comerciales 2
ninguna clase.
2
ESTE DOCUMENTO CONTIENE LA SEMANA 2
ÍNDICE
ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE (SQA) .................................................................. 5

OBJETIVOS ESPECÍFICOS ........................................................................................................................... 5
INTRODUCCIÓN ...................................................................................................................................... 5
1. ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE (SQA) .......................................................... 6
1.1. PROPÓSITO Y OBJETIVO DE SQA ......................................................................................... 6
1.2. ACTIVIDADES DE SQA .......................................................................................................... 7
1.2.1. MONITOREO DE PROCESOS ............................................................................................ 8
1.2.2. EVALUACIÓN DEL PRODUCTO ......................................................................................... 8
1.2.3. AUDITORÍA ...................................................................................................................... 8
1.2.3.1. ESTÁNDARES ............................................................................................................... 9
1.2.3.2. REVISIONES.................................................................................................................. 9
1.2.3.3. PRUEBAS .................................................................................................................... 10
1.2.3.4. ANÁLISIS DE DEFECTOS ............................................................................................. 10
1.2.3.5. GESTIÓN DE LA CONFIGURACIÓN (SCM, SOFTWARE CONFIGURATION
MANAGEMENT)............................................................................................................................. 10
2. ACTIVIDADES DE SQA DURANTE EL CICLO DE DESARROLLO DE SOFTWARE ............................ 11
2.1. EVALUACIÓN (ETAPA DE PLANIFICACIÓN) ........................................................................ 11
2.2. AUDITORÍA (ESPECIFICACIÓN DE REQUERIMIENTOS)....................................................... 11
2.3. MONITOREO (DISEÑO DE SOFTWARE).............................................................................. 11
2.4. AUDITAR (IMPLEMENTACIÓN DE SOFTWARE) .................................................................. 12
2.5. INTEGRACIÓN Y PRUEBA (IMPLEMENTACIÓN DE SOFTWARE) ......................................... 12
2.6. AUDITORÍA (ENTREGA DE SOFTWARE) ............................................................................. 12
3. DOCUMENTACIÓN TÉCNICA DE TRABAJO ASOCIADA A SQA .................................................... 13
3.1.1. DOCUMENTO DE REVISIÓN DE REQUERIMIENTO ......................................................... 13
3.1.2. DOCUMENTO DE REVISIÓN DE DISEÑO ........................................................................ 14
3.1.3. DOCUMENTO DE INSPECCIÓN DE CÓDIGO ................................................................... 14
3.1.4. DOCUMENTO DE REVISIÓN DE USABILIDAD ................................................................. 15
COMENTARIO FINAL.......................................................................................................................... 17
REFERENCIAS........................................................................................................................................ 18
3
ÍNDICE DE FIGURAS
Figura 1: Actividades SQA.................................................................................................................... 7
Figura 2: Modelo de desarrollo en cascada ......................................................................................... 7
ÍNDICE DE TABLAS
Tabla 1: Estructura propuesta documento revisión de requerimiento .............................................. 13
Tabla 2: Estructura propuesta documento revisión de diseño .......................................................... 14
Tabla 3: Estructura propuesta documento revisión código ............................................................... 15
Tabla 4: Estructura propuesta documento revisión de usabilidad .................................................... 16
4
ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE (SQA)
OBJETIVOS ESPECÍFICOS
 Comprender el conjunto de actividades del SQA, destacando la importancia de asegurar la
calidad del software.
 Comprender las actividades de SQA durante el ciclo de vida de desarrollo de software.
 Aplicar la documentación técnica de trabajo referida a SQA.
INTRODUCCIÓN
Un aspecto relevante y necesario dentro de las fases de desarrollo de un proyecto de software es
el aseguramiento de la calidad del software, cuya abreviación en inglés corresponde a SQA
(software quality assurance). Para realizarlo, se requiere establecer un modelo, con formulación
de planes, procedimientos y actividades orientadas a verificar el cumplimiento de los estándares
que se han definido como parte de las prácticas en el desarrollo del software y el proceso que lo
conduce. Entonces, se está hablando de aseguramiento de la calidad del producto de software y
de la aplicación de procedimientos y actividades definidas por un estándar, para conducir el
desarrollo final.
5
1. ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE (SQA)
Antes de iniciar el desarrollo de este tema, se debe señalar que en todo proceso de producción,
debe haber instancias de monitoreo, control y mejora, es decir, actividades orientadas a asegurar
que antes, durante y después del proceso las tareas sean realizadas de la forma como se
planificaron e introducir cambios necesarios para que así sea. Cuando hablamos de un proceso de
desarrollo de software, ocurre exactamente lo mismo.
A continuación, se va desarrollar en detalle el concepto de SQA, donde se abordarán aspectos

relevantes para definir un buen proceso de desarrollo y calidad del software.
1.1. PROPÓSITO Y OBJETIVO DE SQA

Para ejecutar proyectos de desarrollo de software es importante poder asegurar la calidad del
proceso y el producto. Esto se conoce como aseguramiento de la calidad del software (SQA), que
corresponde a un conjunto de actividades estructuradas y definidas en un orden preciso; las cuales
contribuyen a asegurar que las definiciones funcionales y de sistema (definición de
requerimientos) sean correctamente abordadas, como también, en el afán de lograrlo, que se
cumpla con las normativas y estándares que ha definido la organización para realizarlo (Pressman,
2010). Lo anterior se grafica en la Figura 1.
El propósito de SQA es verificar que las actividades declaradas dentro del proceso de desarrollo de
software sean realizadas tal como fueron definidas en la planeación del proyecto. Para aplicarlo,
no importa el tamaño de la organización, se pueden adecuar las funciones de los profesionales, de
manera que exista un rol responsable. Por ejemplo, en una organización pequeña, el mismo
equipo de desarrollo puede abordar estas actividades, como también, en organizaciones más
grandes, habrá un área especializada para tales fines.
De acuerdo a lo anterior, se puede establecer que el aseguramiento de la calidad del software,

tiene por objeto lo siguiente (óp. cit.):
a) Establecer un plan para el aseguramiento de la calidad.

b) Realizar inspecciones en forma sistemática, de manera tal que todo producto y
actividad del proceso sean realizados de acuerdo a los procedimientos y estándares de
la organización.
c) Informar a los distintos actores de la organización respecto a los resultados de las
auditorías realizadas al proceso de desarrollo.
6
Figura 1: Actividades SQA
Fuente: material elaborado para esta asignatura (J. Reyes, 2015)
1.2. ACTIVIDADES DE SQA

Antes que todo se debe situar conceptualmente el ámbito en el cual se definirán las actividades de
SQA. En primer lugar, señalar que la producción de software no surge de la nada, no es
espontánea, sino que más bien cumple un objetivo, el cual a su vez seguramente apalanca otros
objetivos mayores. Es por esta razón que nace el concepto de los proyectos, y estos a su vez, en el
marco de la producción de software, requieren seguir un proceso de desarrollo. Al hablar de
proceso de desarrollo se hace referencia a etapas que van agrupando actividades inherentes a la
producción de software, bajo una lógica de proceso. Por tanto, cada una de las etapas recibe
entradas y define las salidas que requiere la siguiente etapa para comenzar. En la figura a
continuación se muestra un ejemplo de un modelo para desarrollar software (cascada).
Figura 2: Modelo de desarrollo en cascada

7
Si se observa la imagen anterior, existe un conjunto de etapas que comienzan con el análisis y
sucesivamente se van retroalimentando unas a otras como lo muestra el sentido de las flechas. En
cada una de estas etapas hay actividades inherentes al objetivo que persiguen y otras que ayudan
a que estas actividades sean realizadas conforme a los estándares que se han definido en la
organización. Por ejemplo, en la etapa de análisis, se realizará un levantamiento de un
determinado problema y se requerirá documentarlo bajo una cierta estructura. En la etapa de
diseño, se va a establecer el modelo de solución y se hará lo mismo, pero en otro documento.
Finalmente, en la etapa de implementación, se desarrollarán las piezas de software y estas
deberán cumplir con normas de programación. De esta forma, las actividades que gobiernan el
quehacer del equipo de desarrollo corresponden a las actividades propias del aseguramiento de la
calidad del software (óp. cit.). A continuación, se revisarán estas actividades con más detalle.
1.2.1. MONITOREO DE PROCESOS
Actividad que busca verificar la aplicación de procedimientos y su correcto uso en todas las
distintas tareas. Asimismo, que estas vayan en la misma dirección de las definiciones y estándares
establecidos. Desde el punto de vista del proceso, se revisará semanalmente el avance de la
programación, las actividades realizadas, aquellas aún pendientes, la utilización de recursos y se
medirá el avance planificado versus el real respecto al plan del proyecto.
En rigor, el monitoreo de procesos corresponde a un “termómetro” con el cual se mide el grado de

adherencia que tiene el desarrollo del proyecto respecto al estándar definido para realizarlo.
1.2.2. EVALUACIÓN DEL PRODUCTO
Actividad centrada en la calidad del producto y los factores de calidad que se busca destacar. Se
realiza a través de inspecciones a nivel de código, donde se verifica el cumplimiento de normas de
programación y documentación del software.
1.2.3. AUDITORÍA
Corresponde a la actividad en que se inspecciona acuciosamente la ejecución correcta del proceso

de software, como también en que se verifica las características de calidad del producto, tomando
como referencia la adhesión de estas actividades al estándar definido en la organización. Busca
asegurar a través del control que las cosas se estén realizando sobre la base de un proceso
definido y bien aplicado, existiendo la documentación actualizada y chequeando los avances
versus los informes entregados por los grupos de desarrollo. El resultado de la auditoría es un
informe que muestra la adherencia al estándar, las desviaciones y recomendaciones al proceso de
desarrollo de software, como también, entrega visibilidad del estado de los proyectos a la gerencia
o líneas directivas de la organización.
8
Habiendo definido estas tres grandes actividades del SQA, es necesario precisar un poco más el
detalle de las prácticas que le compete a cada una de ellas. Así entonces, se indican a continuación
algunas tareas que incluyen el monitoreo de procesos, la evaluación del producto y las auditorías.
1.2.3.1. ESTÁNDARES
La organización para desarrollar un software de calidad requiere que todo proceso que integra un
conjunto de actividades y métodos que deben ser realizados de acuerdo a una definición
declarada y conocida por todos quienes participan del desarrollo de software. Es importante
destacar que la idea de definirlo busca siempre utilizar buenas prácticas y que los proyectos se
realicen utilizando los mismos criterios procedimentales dentro de la organización. En este
sentido, el criterio es fundamental y se debe ajustar a las necesidades de cada organización. No
todo debe ser estandarizable, esto sería un error. Pero en el ámbito del software, perfectamente
se puede alinear lo siguiente respecto a una definición estándar (óp. cit.):
a. Ciclo de vida del software

b. Documentación del software
c. Normas de programación del software
d. Procedimientos
1.2.3.2. REVISIONES
La revisión es una expresión de monitoreo y evaluación de los entregables o productos de trabajo

durante el ciclo de vida de un producto de software. Ayuda en el proceso de mediciones y
verificación de que lo que se está realizando cumple con el estándar.
Para realizarlas, la organización determina una metodología, con una estructura y disciplina para la
aplicación y detección de desviaciones. Usualmente se puede formular con las siguientes tareas
previas (óp. cit.):
a. Planificación
b. Orientación
c. Preparación
d. Inspección
e. Recomendaciones
f. Seguimiento
El rol principal de SQA es verificar que estas actividades sean realizadas en forma programada
(por eso se planifican) y corroborar que las acciones derivadas de las revisiones sean concretadas.
9
1.2.3.3. PRUEBAS
Esta actividad enfocada en el producto busca verificar que las definiciones funcionales y de
sistemas que definieron su desarrollo se cumplan de acuerdo a lo planeado. Al igual que otras
actividades, la prueba debe ser planificada, ejecutada y finalizar con un informe. Hay que
mencionar que durante el desarrollo de un proyecto de software podemos encontrar pruebas de
desarrollo realizadas por quienes desarrollan el software, pruebas de integración con otros
módulos o sistemas y, finalmente, pruebas de aceptación por parte del usuario final.
En este caso, la labor del SQA también es verificar que lo anterior sea realizado, cumpliendo con
los estándares, generando la documentación requerida e informes que permitan dar visibilidad
respecto del avance del proyecto a las jefaturas respectivas. Así entonces, la misión del SQA se
resume en asegurarse de que (óp. cit.):
a. Los procedimientos de prueba se ajusten a las pruebas necesarias para verificar la

funcionalidad planificada.
b. La versión del software corresponda a la última, con las mejoras incorporadas.
c. Los procedimientos estén revisados y actualizados.
d. Se generen informes de estado del proyecto.
e. Las observaciones sean corregidas antes de las entregas formales.
1.2.3.4. ANÁLISIS DE DEFECTOS
Los defectos se han producido, se producen y seguirán produciéndose mientras existan las
condiciones para que así sea. Es por esta razón que esta actividad es la base para realizar el
análisis causal de ellos. Es así debido a que recoge los antecedentes que se generan a partir del
control de calidad (enfocado al producto) y el aseguramiento de la calidad de este (que observa el
proceso con sus métodos y prácticas). Al analizar estos antecedentes más allá del ámbito del
producto de software en sí, resulta provechoso para las organizaciones, porque se determinan
correcciones al proceso, lo cual indudablemente mejorará la calidad del producto de software en
proyectos futuros (se aprende de los datos registrados y la experiencia).
Así entonces, SQA tiene como responsabilidad la creación de un método que facilite la
identificación de defectos o errores del proceso y proponer los cambios para su mejor desempeño.
1.2.3.5. GESTIÓN DE LA CONFIGURACIÓN (SCM, SOFTWARE CONFIGURATION MANAGEMENT)
El objetivo que persigue esta actividad es asegurar la validez e integridad de las distintas piezas de
software que, integradas, conforman el producto de software durante su desarrollo y posterior
mantenimiento. Para realizar lo anterior, existen cuatro actividades que se deben considerar (óp.
cit.):
10
Identificación de la configuración (componentes y piezas de software de la solución):
a. Elementos de la configuración, así se puede identificar cada una de las versiones de los
componentes del producto de software.
b. Control de los cambios que se van realizando conforme a correcciones e implementación
de lo solicitado según el plan. De esta forma todo cambio en el software queda
documentado y autorizado.
c. Contabilidad, la cual ayuda a llevar un seguimiento en el tiempo de los distintos
componentes de software del producto.
d. Auditorías de configuración, que se encargan de verificar el cumplimiento de los
estándares definidos.
Así la principal tarea del SQA es verificar que se cumpla lo definido en el plan de la administración
de la configuración.
2. ACTIVIDADES DE SQA DURANTE EL CICLO DE DESARROLLO

DE SOFTWARE
2.1. EVALUACIÓN (ETAPA DE PLANIFICACIÓN)

En esta instancia, SQA participa de la elaboración del plan de proyecto. Asimismo, aporta
incorporando procesos, procedimientos y estándares definidos en el plan de proyecto, y además
verifica que sean aplicables, precisos y auditables. Como ya se ha mencionado, el plan del SQA
debe dejar claras las instancias de evaluaciones, auditorías, revisiones, estándares, procedimientos
de seguimiento, los informes de errores y toda documentación acordada para el proyecto (óp.
cit.).
2.2. AUDITORÍA (ESPECIFICACIÓN DE REQUERIMIENTOS)

Esta actividad corrobora que los requerimientos funcionales y de sistema (técnicos) estén
desarrollados para posteriormente verificarlos en el producto final. La organización define las
herramientas para llevar este control y facilitar su gestión durante el proyecto. Hay que recordar
que los requerimientos cambian, sin embargo, al no tener planificada la administración de estos,
es fácil perder el objetivo para el cual se deben desarrollar. En este sentido, el control de cambio
es la manera formal de solicitar una modificación, evaluarla y autorizarla o rechazarla, según las
prioridades e impacto de su ocurrencia o ausencia (óp. cit.).
2.3. MONITOREO (DISEÑO DE SOFTWARE)

Esta actividad tiene por objeto asegurar que el diseño de la solución sea realizado de acuerdo a los
estándares definidos en el plan del proyecto. Esto considera verificar que todos los módulos sean
11
contemplados en el diseño, revisión de los informes de inspección y, finalmente, registrar el
diseño en la administración de la configuración (óp. cit.).
2.4. AUDITAR (IMPLEMENTACIÓN DE SOFTWARE)

El desarrollo o implementación de la solución, además de responder a los requerimientos
funcionales, también debe cumplir con los requerimientos de sistema (técnicos), los
procedimientos de cambios, normas de programación, informes de correcciones, pruebas y
aceptación. En este sentido, la actividad del SQA verifica el estado de todos los entregables, los
procedimientos de cambio y administración de la configuración (óp. cit.).
2.5. INTEGRACIÓN Y PRUEBA (IMPLEMENTACIÓN DE SOFTWARE)

Como se ha mencionado anteriormente, esta actividad también requiere que SQA vele por la
correspondencia entre las pruebas, el plan y los procedimientos definidos para realizarlas. Así
también, por los informes y resultados obtenidos, los cuales deben ser informados en forma clara,
y por qué las correcciones acordadas sean resueltas para una nueva revisión. Una vez finalizada la
etapa de pruebas, debe certificar que el software cumpla satisfactoriamente con lo planificado y
que cuente con la documentación actualizada (óp. cit.).
2.6. AUDITORÍA (ENTREGA DE SOFTWARE)

En esta actividad, se realiza una certificación conforme a lo anteriormente realizado y verificando:
que los entregables y su configuración sean los correctos para ser puestos a disposición del
solicitante (óp. cit.).
12
3. DOCUMENTACIÓN TÉCNICA DE TRABAJO ASOCIADA A SQA
La actividad de SQA se puede apoyar en herramientas para materializar las tareas que requiere
realizar durante el desarrollo del proyecto. Por tal razón se indica una guía para orientar la
elaboración de estos “artefactos”.
3.1.1. DOCUMENTO DE REVISIÓN DE REQUERIMIENTO
Este documento corresponde a una guía para hacer una revisión precisa de la definición y
elaboración de los requerimientos que forman parte de la solución final, y así verificar la
completitud y adherencia al estándar que debe utilizarse para su definición. De esta forma, la
estructura que puede orientar la elaboración del documento puede ser la siguiente:
Propósito Actividad Descripción/Detalle

Entrada  Identificar lista de  Se solicitan antecedentes del proyecto
requerimientos definidos de (definición de requerimientos) a la dirección
acuerdo a la planificación del mismo o equipo de desarrollo.
del proyecto (deben estar
todos).
Revisión  Verificar que su elaboración  Programar esta actividad con el equipo de

satisfaga las definiciones desarrollo.
funcionales y de sistema;
como también la
adherencia a los estándares
y procedimientos aplicados
en su formulación y detalle.
Salida  Consolidación del resultado  Informar a la dirección del proyecto,

de la revisión y generación solicitando revisión y definiendo fecha de
de informe de errores y entrega de las correcciones.
observaciones.
Tabla 1: Estructura propuesta documento revisión de requerimiento

13
3.1.2. DOCUMENTO DE REVISIÓN DE DISEÑO
Este documento es una guía para revisar el diseño de la solución y verificar que se hayan
considerado todos los aspectos definidos en la planificación del proyecto. Es decir, se debe abarcar
todo lo requerido en términos técnicos y funcionales, como la adherencia a los estándares y
procedimientos definidos por la organización para la ejecución de las actividades de esta etapa.
Así, la estructura que oriente la elaboración de este documento puede ser la siguiente (óp. cit.):

Entrada  Lista de requerimientos  Se solicita al equipo de desarrollo la
funcionales y de sistema de definición de diseño elaborada, o bien el
la solución. avance de lo realizado.
 Definición del diseño de la
solución.
 Estándares y
procedimientos de diseño.
Revisión  Verificar la correcta  Programar esta actividad con el equipo de

aplicación de estándares y desarrollo.
procedimientos para el
diseño de la solución.
 Excepciones declaradas de
no aplicación de las normas
en casos precisos.

observaciones.
Tabla 2: Estructura propuesta documento revisión de diseño

3.1.3. DOCUMENTO DE INSPECCIÓN DE CÓDIGO
Este documento corresponde a una guía para hacer una inspección del código fuente de la
solución. Sobre la base de una normativa de programación, se debe verificar que esta se aplique
en los distintos ámbitos de la programación. Por ejemplo, normas para la programación y
normalización de bases de datos, normas para el desarrollo web, en relación al uso del lenguaje de
programación utilizado, entre otros. De esta forma, la estructura que puede orientar la
elaboración del documento puede ser la siguiente (óp. cit.):
14
Entrada  Lista de objetos y  Se solicita al equipo de desarrollo que
componentes de software indique la última configuración actualizada
en proceso de desarrollo. de ítems de programación. Esto es,
 Normas de programación. componentes y piezas de software
 Procedimientos de
configuración de
componentes de software.
Revisión  Se puede apoyar a través de  Programar esta actividad con el equipo de

un software que aplique las desarrollo.
reglas de validación en el
uso del lenguaje de
programación.
 Seleccionar algunos ítems
de programación y revisar
su adherencia a las normas
definidas por la
organización.
en casos precisos.

observaciones.
Tabla 3: Estructura propuesta documento revisión código

3.1.4. DOCUMENTO DE REVISIÓN DE USABILIDAD
La usabilidad como definición de una solución no es una simple declaración de buenas ideas o
eventuales facilidades para el usuario final en su futura interacción con la solución de software.
Resulta algo más complejo y debe estar debidamente alineado con la definición inicial de la
necesidad y expectativas funcionales que declare el usuario.
De esta forma, la usabilidad comienza con una participación directa en la definición de sus
requerimientos funcionales e incorporando sus preferencias respecto a experiencias anteriores en
el uso de sistemas. Por ejemplo, el usuario por nada del mundo espera un buscador de clientes
con una cantidad insoportable de parámetros de búsqueda, cuando usualmente lo que hace es
ingresar el nombre o RUN para identificarlo. Así también, indica los tipos de formato que deben
tener los datos para su mejor comprensión.
15
La accesibilidad es otro referente en este ámbito. Navegar dentro de muchas pantallas para llegar
a un dato seguramente es lo que el usuario tratará de evitar. Por tanto el diseño será clave para
incorporar este tipo de requerimientos en su propuesta de despliegue de información.
Si un sistema no tiene la capacidad de comportarse de la misma manera sobre distintas

plataformas de software o hardware, afectará su utilización. Por ejemplo, en organizaciones
donde coexisten más de un tipo plataformas.
Visualmente, también hay preferencias y características que el usuario persigue. Entonces, estas
deben ser materializadas en el diseño. Por ejemplo, un mismo sistema el usuario necesita sea
desplegado en un ambiente mobile1, como también en un browser tradicional sobre la web.
Lo concreto es que para verificar la usabilidad debe haber una instancia y herramientas que
ayuden a corroborar lo solicitado en los requerimientos funcionales y de sistema por el usuario.
De esta forma, la estructura que oriente la elaboración del documento puede ser la siguiente (óp.
cit.):

Entrada  Lista de requerimientos  Se solicita al equipo de desarrollo la
funcionales y de sistema de definición de diseño elaborada, o bien
la solución. En este caso, avance de lo realizado.
con un énfasis en aquellos
requerimientos de
usabilidad del sistema.
 Estándares y
procedimientos de diseño.
Revisión  Verificar que los aspectos  Programar esta actividad con el equipo de
de usabilidad declarados en desarrollo.
la definición de
requerimientos del usuario
estén desarrollados en
forma clara y precisa.
en casos precisos.

observaciones.
Tabla 4: Estructura propuesta documento revisión de usabilidad

1
Mobile técnicamente se refiere a las tecnologías que tienen conectividad con internet, de acuerdo a
estándares definidos para ello. Es una castellanización del término inglés.
16
COMENTARIO FINAL
La actividad de aseguramiento de la calidad del software (SQA) es el mecanismo a través del cual
una organización puede resguardar que el producto de software final sea desarrollado sobre la
base de buenas prácticas, considerando los aspectos funcionales y técnicos determinados en el
plan del proyecto. Lo anterior no será posible en ausencia de estándares y procedimientos que
integren buenas prácticas y la acción realizada por SQA, para asegurar que lo desarrollado cumpla
o adhiera a estas definiciones.
17
REFERENCIAS
Piattini, M.; García, F.; García, I. y Pino, F. (2012). Calidad de sistemas de información. México:
Alfaomega Grupo Editor. Madrid: Ra-Ma.
Piattini, M. (2008). Medición y estimación del software. Técnicas y métodos para mejorar la calidad
y la productividad. México: Alfaomega Grupo Editor. Madrid: Ra-Ma.
Pressman, R. (2010). Ingeniería de Software, un enfoque práctico. 7.ª edición. España: Editorial
McGraw-Hill Interamericana S. A.
PARA REFERENCIAR ESTE DOCUMENTO, CONSIDERE:
IACC (2015). Aseguramiento de la calidad del software (SQA). Modelos y Control de Calidad.
Semana 2.
18
19

02 Modelos y Control de Calidad PDF

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

02 Modelos y Control de Calidad PDF

Cargado por

Copyright:

Formatos disponibles

MODELOS Y CONTROL DE CALIDAD

ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE (SQA) .................................................................. 5

A continuación, se va desarrollar en detalle el concepto de SQA, donde se abordarán aspectos

1.1. PROPÓSITO Y OBJETIVO DE SQA

De acuerdo a lo anterior, se puede establecer que el aseguramiento de la calidad del software,

a) Establecer un plan para el aseguramiento de la calidad.

1.2. ACTIVIDADES DE SQA

Figura 2: Modelo de desarrollo en cascada

1.2.1. MONITOREO DE PROCESOS

En rigor, el monitoreo de procesos corresponde a un “termómetro” con el cual se mide el grado de

1.2.2. EVALUACIÓN DEL PRODUCTO

Corresponde a la actividad en que se inspecciona acuciosamente la ejecución correcta del proceso

a. Ciclo de vida del software

La revisión es una expresión de monitoreo y evaluación de los entregables o productos de trabajo

a. Los procedimientos de prueba se ajusten a las pruebas necesarias para verificar la

1.2.3.4. ANÁLISIS DE DEFECTOS

1.2.3.5. GESTIÓN DE LA CONFIGURACIÓN (SCM, SOFTWARE CONFIGURATION MANAGEMENT)

2. ACTIVIDADES DE SQA DURANTE EL CICLO DE DESARROLLO

2.1. EVALUACIÓN (ETAPA DE PLANIFICACIÓN)

2.2. AUDITORÍA (ESPECIFICACIÓN DE REQUERIMIENTOS)

2.3. MONITOREO (DISEÑO DE SOFTWARE)

2.4. AUDITAR (IMPLEMENTACIÓN DE SOFTWARE)

2.5. INTEGRACIÓN Y PRUEBA (IMPLEMENTACIÓN DE SOFTWARE)

2.6. AUDITORÍA (ENTREGA DE SOFTWARE)

3.1.1. DOCUMENTO DE REVISIÓN DE REQUERIMIENTO

Propósito Actividad Descripción/Detalle

Revisión  Verificar que su elaboración  Programar esta actividad con el equipo de

Salida  Consolidación del resultado  Informar a la dirección del proyecto,

Tabla 1: Estructura propuesta documento revisión de requerimiento

Propósito Actividad Descripción/Detalle

Revisión  Verificar la correcta  Programar esta actividad con el equipo de

Salida  Consolidación del resultado  Informar a la dirección del proyecto,

Tabla 2: Estructura propuesta documento revisión de diseño

3.1.3. DOCUMENTO DE INSPECCIÓN DE CÓDIGO

Revisión  Se puede apoyar a través de  Programar esta actividad con el equipo de

Salida  Consolidación del resultado  Informar a la dirección del proyecto,

Tabla 3: Estructura propuesta documento revisión código

3.1.4. DOCUMENTO DE REVISIÓN DE USABILIDAD

Si un sistema no tiene la capacidad de comportarse de la misma manera sobre distintas

Propósito Actividad Descripción/Detalle

Salida  Consolidación del resultado  Informar a la dirección del proyecto,

Tabla 4: Estructura propuesta documento revisión de usabilidad

Alfaomega Grupo Editor. Madrid: Ra-Ma.

y la productividad. México: Alfaomega Grupo Editor. Madrid: Ra-Ma.

PARA REFERENCIAR ESTE DOCUMENTO, CONSIDERE:

También podría gustarte