02 Modelos y Control de Calidad

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 disposicin del pblico 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 ESPECFICOS ........................................................................................................................... 5
INTRODUCCIN ...................................................................................................................................... 5
1. ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE (SQA) .......................................................... 6
1.1. PROPSITO Y OBJETIVO DE SQA ......................................................................................... 6
1.2. ACTIVIDADES DE SQA .......................................................................................................... 7
1.2.1. MONITOREO DE PROCESOS ............................................................................................ 8
1.2.2. EVALUACIN DEL PRODUCTO ......................................................................................... 8
1.2.3. AUDITORA ...................................................................................................................... 8
1.2.3.1. ESTNDARES ............................................................................................................... 9
1.2.3.2. REVISIONES.................................................................................................................. 9
1.2.3.3. PRUEBAS .................................................................................................................... 10
1.2.3.4. ANLISIS DE DEFECTOS ............................................................................................. 10
1.2.3.5. GESTIN DE LA CONFIGURACIN (SCM, SOFTWARE CONFIGURATION
MANAGEMENT)............................................................................................................................. 10
2. ACTIVIDADES DE SQA DURANTE EL CICLO DE DESARROLLO DE SOFTWARE ............................ 11
2.1. EVALUACIN (ETAPA DE PLANIFICACIN) ........................................................................ 11
2.2. AUDITORA (ESPECIFICACIN DE REQUERIMIENTOS)....................................................... 11
2.3. MONITOREO (DISEO DE SOFTWARE).............................................................................. 11
2.4. AUDITAR (IMPLEMENTACIN DE SOFTWARE) .................................................................. 12
2.5. INTEGRACIN Y PRUEBA (IMPLEMENTACIN DE SOFTWARE) ......................................... 12
2.6. AUDITORA (ENTREGA DE SOFTWARE) ............................................................................. 12
3. DOCUMENTACIN TCNICA DE TRABAJO ASOCIADA A SQA .................................................... 13
3.1.1. DOCUMENTO DE REVISIN DE REQUERIMIENTO ......................................................... 13
3.1.2. DOCUMENTO DE REVISIN DE DISEO ........................................................................ 14
3.1.3. DOCUMENTO DE INSPECCIN DE CDIGO ................................................................... 14
3.1.4. DOCUMENTO DE REVISIN 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 revisin de requerimiento .............................................. 13
Tabla 2: Estructura propuesta documento revisin de diseo .......................................................... 14
Tabla 3: Estructura propuesta documento revisin cdigo ............................................................... 15
Tabla 4: Estructura propuesta documento revisin de usabilidad .................................................... 16
4
ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE (SQA)
OBJETIVOS ESPECFICOS
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 documentacin tcnica de trabajo referida a SQA.
INTRODUCCIN
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 abreviacin en ingls corresponde a SQA
(software quality assurance). Para realizarlo, se requiere establecer un modelo, con formulacin
de planes, procedimientos y actividades orientadas a verificar el cumplimiento de los estndares
que se han definido como parte de las prcticas 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 aplicacin de procedimientos y actividades definidas por un estndar, para conducir el
desarrollo final.
5
1. ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE (SQA)
Antes de iniciar el desarrollo de este tema, se debe sealar que en todo proceso de produccin,
debe haber instancias de monitoreo, control y mejora, es decir, actividades orientadas a asegurar
que antes, durante y despus 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 continuacin, se va desarrollar en detalle el concepto de SQA, donde se abordarn aspectos

relevantes para definir un buen proceso de desarrollo y calidad del software.
1.1. PROPSITO 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 (definicin de
requerimientos) sean correctamente abordadas, como tambin, en el afn de lograrlo, que se
cumpla con las normativas y estndares que ha definido la organizacin para realizarlo (Pressman,
2010). Lo anterior se grafica en la Figura 1.
El propsito de SQA es verificar que las actividades declaradas dentro del proceso de desarrollo de
software sean realizadas tal como fueron definidas en la planeacin del proyecto. Para aplicarlo,
no importa el tamao de la organizacin, se pueden adecuar las funciones de los profesionales, de
manera que exista un rol responsable. Por ejemplo, en una organizacin pequea, el mismo
equipo de desarrollo puede abordar estas actividades, como tambin, en organizaciones ms
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 sistemtica, de manera tal que todo producto y
actividad del proceso sean realizados de acuerdo a los procedimientos y estndares de
la organizacin.
c) Informar a los distintos actores de la organizacin respecto a los resultados de las
auditoras 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 definirn las actividades de
SQA. En primer lugar, sealar que la produccin de software no surge de la nada, no es
espontnea, sino que ms bien cumple un objetivo, el cual a su vez seguramente apalanca otros
objetivos mayores. Es por esta razn que nace el concepto de los proyectos, y estos a su vez, en el
marco de la produccin 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
produccin de software, bajo una lgica 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
continuacin 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 anlisis 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 estndares que se han definido en la
organizacin. Por ejemplo, en la etapa de anlisis, se realizar un levantamiento de un
determinado problema y se requerir documentarlo bajo una cierta estructura. En la etapa de
diseo, se va a establecer el modelo de solucin y se har lo mismo, pero en otro documento.
Finalmente, en la etapa de implementacin, se desarrollarn las piezas de software y estas
debern cumplir con normas de programacin. 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 continuacin, se revisarn estas actividades con ms detalle.
1.2.1. MONITOREO DE PROCESOS
Actividad que busca verificar la aplicacin de procedimientos y su correcto uso en todas las
distintas tareas. Asimismo, que estas vayan en la misma direccin de las definiciones y estndares
establecidos. Desde el punto de vista del proceso, se revisar semanalmente el avance de la
programacin, las actividades realizadas, aquellas an pendientes, la utilizacin 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 termmetro con el cual se mide el grado de

adherencia que tiene el desarrollo del proyecto respecto al estndar definido para realizarlo.
1.2.2. EVALUACIN DEL PRODUCTO
Actividad centrada en la calidad del producto y los factores de calidad que se busca destacar. Se
realiza a travs de inspecciones a nivel de cdigo, donde se verifica el cumplimiento de normas de
programacin y documentacin del software.
1.2.3. AUDITORA
Corresponde a la actividad en que se inspecciona acuciosamente la ejecucin correcta del proceso

de software, como tambin en que se verifica las caractersticas de calidad del producto, tomando
como referencia la adhesin de estas actividades al estndar definido en la organizacin. Busca
asegurar a travs del control que las cosas se estn realizando sobre la base de un proceso
definido y bien aplicado, existiendo la documentacin actualizada y chequeando los avances
versus los informes entregados por los grupos de desarrollo. El resultado de la auditora es un
informe que muestra la adherencia al estndar, las desviaciones y recomendaciones al proceso de
desarrollo de software, como tambin, entrega visibilidad del estado de los proyectos a la gerencia
o lneas directivas de la organizacin.
8
Habiendo definido estas tres grandes actividades del SQA, es necesario precisar un poco ms el
detalle de las prcticas que le compete a cada una de ellas. As entonces, se indican a continuacin
algunas tareas que incluyen el monitoreo de procesos, la evaluacin del producto y las auditoras.
1.2.3.1. ESTNDARES
La organizacin para desarrollar un software de calidad requiere que todo proceso que integra un
conjunto de actividades y mtodos que deben ser realizados de acuerdo a una definicin
declarada y conocida por todos quienes participan del desarrollo de software. Es importante
destacar que la idea de definirlo busca siempre utilizar buenas prcticas y que los proyectos se
realicen utilizando los mismos criterios procedimentales dentro de la organizacin. En este
sentido, el criterio es fundamental y se debe ajustar a las necesidades de cada organizacin. No
todo debe ser estandarizable, esto sera un error. Pero en el mbito del software, perfectamente
se puede alinear lo siguiente respecto a una definicin estndar (p. cit.):
a. Ciclo de vida del software

b. Documentacin del software
c. Normas de programacin del software
d. Procedimientos
1.2.3.2. REVISIONES
La revisin es una expresin de monitoreo y evaluacin de los entregables o productos de trabajo

durante el ciclo de vida de un producto de software. Ayuda en el proceso de mediciones y
verificacin de que lo que se est realizando cumple con el estndar.
Para realizarlas, la organizacin determina una metodologa, con una estructura y disciplina para la
aplicacin y deteccin de desviaciones. Usualmente se puede formular con las siguientes tareas
previas (p. cit.):
a. Planificacin
b. Orientacin
c. Preparacin
d. Inspeccin
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 integracin con otros
mdulos o sistemas y, finalmente, pruebas de aceptacin por parte del usuario final.
En este caso, la labor del SQA tambin es verificar que lo anterior sea realizado, cumpliendo con
los estndares, generando la documentacin requerida e informes que permitan dar visibilidad
respecto del avance del proyecto a las jefaturas respectivas. As entonces, la misin 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 versin del software corresponda a la ltima, con las mejoras incorporadas.
c. Los procedimientos estn 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. ANLISIS DE DEFECTOS
Los defectos se han producido, se producen y seguirn producindose mientras existan las
condiciones para que as sea. Es por esta razn que esta actividad es la base para realizar el
anlisis 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 mtodos y prcticas). Al analizar estos antecedentes ms 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 creacin de un mtodo que facilite la

identificacin de defectos o errores del proceso y proponer los cambios para su mejor desempeo.
1.2.3.5. GESTIN DE LA CONFIGURACIN (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
Identificacin de la configuracin (componentes y piezas de software de la solucin):
a. Elementos de la configuracin, 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 implementacin
de lo solicitado segn 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. Auditoras de configuracin, que se encargan de verificar el cumplimiento de los
estndares definidos.
As la principal tarea del SQA es verificar que se cumpla lo definido en el plan de la administracin
de la configuracin.
2. ACTIVIDADES DE SQA DURANTE EL CICLO DE DESARROLLO

DE SOFTWARE
2.1. EVALUACIN (ETAPA DE PLANIFICACIN)

En esta instancia, SQA participa de la elaboracin del plan de proyecto. Asimismo, aporta
incorporando procesos, procedimientos y estndares definidos en el plan de proyecto, y adems
verifica que sean aplicables, precisos y auditables. Como ya se ha mencionado, el plan del SQA
debe dejar claras las instancias de evaluaciones, auditoras, revisiones, estndares, procedimientos
de seguimiento, los informes de errores y toda documentacin acordada para el proyecto (p.
cit.).
2.2. AUDITORA (ESPECIFICACIN DE REQUERIMIENTOS)

Esta actividad corrobora que los requerimientos funcionales y de sistema (tcnicos) estn
desarrollados para posteriormente verificarlos en el producto final. La organizacin define las
herramientas para llevar este control y facilitar su gestin durante el proyecto. Hay que recordar
que los requerimientos cambian, sin embargo, al no tener planificada la administracin de estos,
es fcil perder el objetivo para el cual se deben desarrollar. En este sentido, el control de cambio
es la manera formal de solicitar una modificacin, evaluarla y autorizarla o rechazarla, segn las
prioridades e impacto de su ocurrencia o ausencia (p. cit.).
2.3. MONITOREO (DISEO DE SOFTWARE)

Esta actividad tiene por objeto asegurar que el diseo de la solucin sea realizado de acuerdo a los
estndares definidos en el plan del proyecto. Esto considera verificar que todos los mdulos sean
11
contemplados en el diseo, revisin de los informes de inspeccin y, finalmente, registrar el
diseo en la administracin de la configuracin (p. cit.).
2.4. AUDITAR (IMPLEMENTACIN DE SOFTWARE)

El desarrollo o implementacin de la solucin, adems de responder a los requerimientos
funcionales, tambin debe cumplir con los requerimientos de sistema (tcnicos), los
procedimientos de cambios, normas de programacin, informes de correcciones, pruebas y
aceptacin. En este sentido, la actividad del SQA verifica el estado de todos los entregables, los
procedimientos de cambio y administracin de la configuracin (p. cit.).
2.5. INTEGRACIN Y PRUEBA (IMPLEMENTACIN DE SOFTWARE)

Como se ha mencionado anteriormente, esta actividad tambin requiere que SQA vele por la
correspondencia entre las pruebas, el plan y los procedimientos definidos para realizarlas. As
tambin, 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 revisin. Una vez finalizada la
etapa de pruebas, debe certificar que el software cumpla satisfactoriamente con lo planificado y
que cuente con la documentacin actualizada (p. cit.).
2.6. AUDITORA (ENTREGA DE SOFTWARE)

En esta actividad, se realiza una certificacin conforme a lo anteriormente realizado y verificando:
que los entregables y su configuracin sean los correctos para ser puestos a disposicin del
solicitante (p. cit.).
12
3. DOCUMENTACIN TCNICA 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 razn se indica una gua para orientar la
elaboracin de estos artefactos.
3.1.1. DOCUMENTO DE REVISIN DE REQUERIMIENTO
Este documento corresponde a una gua para hacer una revisin precisa de la definicin y
elaboracin de los requerimientos que forman parte de la solucin final, y as verificar la
completitud y adherencia al estndar que debe utilizarse para su definicin. De esta forma, la
estructura que puede orientar la elaboracin del documento puede ser la siguiente:
Propsito Actividad Descripcin/Detalle

Entrada Identificar lista de Se solicitan antecedentes del proyecto
requerimientos definidos de (definicin de requerimientos) a la direccin
acuerdo a la planificacin del mismo o equipo de desarrollo.
del proyecto (deben estar
todos).
Revisin Verificar que su elaboracin Programar esta actividad con el equipo de

satisfaga las definiciones desarrollo.
funcionales y de sistema;
como tambin la
adherencia a los estndares
y procedimientos aplicados
en su formulacin y detalle.
Salida Consolidacin del resultado Informar a la direccin del proyecto,

de la revisin y generacin solicitando revisin y definiendo fecha de
de informe de errores y entrega de las correcciones.
observaciones.
Tabla 1: Estructura propuesta documento revisin de requerimiento

13
3.1.2. DOCUMENTO DE REVISIN DE DISEO
Este documento es una gua para revisar el diseo de la solucin y verificar que se hayan
considerado todos los aspectos definidos en la planificacin del proyecto. Es decir, se debe abarcar
todo lo requerido en trminos tcnicos y funcionales, como la adherencia a los estndares y
procedimientos definidos por la organizacin para la ejecucin de las actividades de esta etapa.
As, la estructura que oriente la elaboracin 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 definicin de diseo elaborada, o bien el
la solucin. avance de lo realizado.
Definicin del diseo de la
solucin.
Estndares y
procedimientos de diseo.
Revisin Verificar la correcta Programar esta actividad con el equipo de

aplicacin de estndares y desarrollo.
procedimientos para el
diseo de la solucin.
Excepciones declaradas de
no aplicacin de las normas
en casos precisos.

observaciones.
Tabla 2: Estructura propuesta documento revisin de diseo

3.1.3. DOCUMENTO DE INSPECCIN DE CDIGO
Este documento corresponde a una gua para hacer una inspeccin del cdigo fuente de la
solucin. Sobre la base de una normativa de programacin, se debe verificar que esta se aplique
en los distintos mbitos de la programacin. Por ejemplo, normas para la programacin y
normalizacin de bases de datos, normas para el desarrollo web, en relacin al uso del lenguaje de
programacin utilizado, entre otros. De esta forma, la estructura que puede orientar la
elaboracin 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 configuracin actualizada
en proceso de desarrollo. de tems de programacin. Esto es,
Normas de programacin. componentes y piezas de software
Procedimientos de
configuracin de
componentes de software.
Revisin Se puede apoyar a travs de Programar esta actividad con el equipo de

un software que aplique las desarrollo.
reglas de validacin en el
uso del lenguaje de
programacin.
Seleccionar algunos tems
de programacin y revisar
su adherencia a las normas
definidas por la
organizacin.
en casos precisos.

observaciones.
Tabla 3: Estructura propuesta documento revisin cdigo

3.1.4. DOCUMENTO DE REVISIN DE USABILIDAD
La usabilidad como definicin de una solucin no es una simple declaracin de buenas ideas o
eventuales facilidades para el usuario final en su futura interaccin con la solucin de software.
Resulta algo ms complejo y debe estar debidamente alineado con la definicin inicial de la
necesidad y expectativas funcionales que declare el usuario.
De esta forma, la usabilidad comienza con una participacin directa en la definicin 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 parmetros de bsqueda, cuando usualmente lo que hace es
ingresar el nombre o RUN para identificarlo. As tambin, indica los tipos de formato que deben
tener los datos para su mejor comprensin.
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 diseo ser clave para
incorporar este tipo de requerimientos en su propuesta de despliegue de informacin.
Si un sistema no tiene la capacidad de comportarse de la misma manera sobre distintas

plataformas de software o hardware, afectar su utilizacin. Por ejemplo, en organizaciones
donde coexisten ms de un tipo plataformas.
Visualmente, tambin hay preferencias y caractersticas que el usuario persigue. Entonces, estas
deben ser materializadas en el diseo. Por ejemplo, un mismo sistema el usuario necesita sea
desplegado en un ambiente mobile1, como tambin 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 elaboracin del documento puede ser la siguiente (p.
cit.):

Entrada Lista de requerimientos Se solicita al equipo de desarrollo la
funcionales y de sistema de definicin de diseo elaborada, o bien
la solucin. En este caso, avance de lo realizado.
con un nfasis en aquellos
requerimientos de
usabilidad del sistema.
Estndares y
procedimientos de diseo.
Revisin Verificar que los aspectos Programar esta actividad con el equipo de
de usabilidad declarados en desarrollo.
la definicin de
requerimientos del usuario
estn desarrollados en
forma clara y precisa.
en casos precisos.

observaciones.
Tabla 4: Estructura propuesta documento revisin de usabilidad

1
Mobile tcnicamente se refiere a las tecnologas que tienen conectividad con internet, de acuerdo a
estndares definidos para ello. Es una castellanizacin del trmino ingls.
16
COMENTARIO FINAL
La actividad de aseguramiento de la calidad del software (SQA) es el mecanismo a travs del cual
una organizacin puede resguardar que el producto de software final sea desarrollado sobre la
base de buenas prcticas, considerando los aspectos funcionales y tcnicos determinados en el
plan del proyecto. Lo anterior no ser posible en ausencia de estndares y procedimientos que
integren buenas prcticas y la accin realizada por SQA, para asegurar que lo desarrollado cumpla
o adhiera a estas definiciones.
17
REFERENCIAS
Piattini, M.; Garca, F.; Garca, I. y Pino, F. (2012). Calidad de sistemas de informacin. Mxico:
Alfaomega Grupo Editor. Madrid: Ra-Ma.
Piattini, M. (2008). Medicin y estimacin del software. Tcnicas y mtodos para mejorar la calidad
y la productividad. Mxico: Alfaomega Grupo Editor. Madrid: Ra-Ma.
Pressman, R. (2010). Ingeniera de Software, un enfoque prctico. 7. edicin. Espaa: 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

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

02 Modelos y Control de Calidad

Uploaded by

Copyright:

Available Formats

MODELOS Y CONTROL DE CALIDAD

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

A continuacin, se va desarrollar en detalle el concepto de SQA, donde se abordarn aspectos

1.1. PROPSITO 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 termmetro con el cual se mide el grado de

1.2.2. EVALUACIN DEL PRODUCTO

Corresponde a la actividad en que se inspecciona acuciosamente la ejecucin correcta del proceso

a. Ciclo de vida del software

La revisin es una expresin de monitoreo y evaluacin 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. ANLISIS DE DEFECTOS

As entonces, SQA tiene como responsabilidad la creacin de un mtodo que facilite la

1.2.3.5. GESTIN DE LA CONFIGURACIN (SCM, SOFTWARE CONFIGURATION MANAGEMENT)

a. Elementos de la configuracin, as se puede identificar cada una de las versiones de los

2. ACTIVIDADES DE SQA DURANTE EL CICLO DE DESARROLLO

2.1. EVALUACIN (ETAPA DE PLANIFICACIN)

2.2. AUDITORA (ESPECIFICACIN DE REQUERIMIENTOS)

2.3. MONITOREO (DISEO DE SOFTWARE)

2.4. AUDITAR (IMPLEMENTACIN DE SOFTWARE)

2.5. INTEGRACIN Y PRUEBA (IMPLEMENTACIN DE SOFTWARE)

2.6. AUDITORA (ENTREGA DE SOFTWARE)

3.1.1. DOCUMENTO DE REVISIN DE REQUERIMIENTO

Propsito Actividad Descripcin/Detalle

Revisin Verificar que su elaboracin Programar esta actividad con el equipo de

Salida Consolidacin del resultado Informar a la direccin del proyecto,

Tabla 1: Estructura propuesta documento revisin de requerimiento

Propsito Actividad Descripcin/Detalle

Revisin Verificar la correcta Programar esta actividad con el equipo de

Salida Consolidacin del resultado Informar a la direccin del proyecto,

Tabla 2: Estructura propuesta documento revisin de diseo

3.1.3. DOCUMENTO DE INSPECCIN DE CDIGO

Revisin Se puede apoyar a travs de Programar esta actividad con el equipo de

Salida Consolidacin del resultado Informar a la direccin del proyecto,

Tabla 3: Estructura propuesta documento revisin cdigo

3.1.4. DOCUMENTO DE REVISIN DE USABILIDAD

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

Propsito Actividad Descripcin/Detalle

Salida Consolidacin del resultado Informar a la direccin del proyecto,

Tabla 4: Estructura propuesta documento revisin de usabilidad

Alfaomega Grupo Editor. Madrid: Ra-Ma.

y la productividad. Mxico: Alfaomega Grupo Editor. Madrid: Ra-Ma.

Pressman, R. (2010). Ingeniera de Software, un enfoque prctico. 7. edicin. Espaa: Editorial

PARA REFERENCIAR ESTE DOCUMENTO, CONSIDERE:

You might also like