Aplicaciones de Ingeniera de

Software
Administracin de la Calidad
del Producto de Software

Qu es la gestin de la
calidad?

Es una actividad protectora o de

sombrilla que se aplica a lo largo del
proceso de software.
Con frecuencia es llamada garanta de
la calidad de software

La gestin de la calidad abarca

Un proceso de garanta de la calidad del

software (Software Quality Assurer/Advisor)

Tareas especficas de aseguramiento y

control de la calidad (revisiones tcnicas
formales y una estrategia de pruebas)

Prcticas efectivas de ingeniera de

software (mtodos y herramientas)

La gestin de la calidad abarca

Control

de todos los productos de trabajo del

software y los cambios que generan
Un

procedimiento para garantizar la

concordancia con los estndares de
desarrollo del software
Mecanismos

de medicin e informe

Control de calidad

Involucra la serie de inspecciones,

revisiones y pruebas empleadas a lo
largo del proceso de software para
garantizar que cada producto de
trabajo satisfaga los requisitos que se
le han asignado.

Garanta de la calidad del

software (SQA)
Concordancia con los requisitos funcionales
y
de
desempeo
explcitamente
establecidos, estndares de desarrollo
explcitamente
documentados
y
caractersticas implcitas que se esperan de
cualquier
software
desarrollado
profesionalmente.

La gente olvida cun rpido hiciste un

trabajo, pero siempre recuerdan cun
bien lo hiciste.
Howard Newton

Actividades de SQA

Preparar un plan de SQA para un

proyecto.
Identifica las evaluaciones que se harn,
las auditoras y revisiones a llevar a cabo,
los estndares aplicables al proyecto, los
procedimientos para el informe y el
seguimiento de errores, los documentos
que debe producir el grupo SQA y la
cantidad de retroalimentacin
proporcionada al equipo de proyecto.

Actividades de SQA

Participar en el desarrollo de la
descripcin del proceso de software del
proyecto.
El equipo de software selecciona un proceso
para el trabajo que habr de realizarse. El
grupo de SQA revisa la descripcin del
proceso para que concuerde con las polticas
organizacionales, los estndares internos de
software, los estndares impuestos de
manera externa (ISO 9000) y otras partes del
plan de proyecto de software.

Actividades de SQA

Revisar las actividades de ingeniera del

software para verificar que se ajustan al
proceso de software definido.
El grupo de SQA identifica, documenta y sigue
las desviaciones del proceso y verifica que se
hayan hecho las correcciones.

Actividades de SQA

Audita productos de trabajo de software

seleccionados para verificar que se ajusten
con los definidos como parte del proceso
del software.
El grupo de SQA revisa los productos de
trabajo seleccionados, identifica, documenta y
sigue las desviaciones; verifica que se hayan
hecho las correcciones; y peridicamente
informa de los resultados de su trabajo al
gerente del proyecto.

Actividades de SQA

Garantiza que las desviaciones en el

trabajo del software y en los productos
de trabajo estn documentadas y se
manejen
de
acuerdo
con
el
procedimiento establecido.
Las desviaciones se pueden encontrar en el
plan del proyecto, en la descripcin del
proceso, en los estndares aplicables o en
los productos de trabajo tcnicos.

Actividades de SQA

Registra cualquier falta de ajuste y

lo informa al gestor ejecutivo.
A los seguimientos que no se ajustan
se les da seguimiento hasta
resolverlos.

Validacin

La validacin se refiere al proceso de

evaluacin del software al final de su
desarrollo para asegurar que est libre de
fallas y cumple con los requisitos.
La validacin se lleva a cabo mediante la
utilizacin de diversos enfoques de prueba.
Tambin se pueden validar productos
intermedios como la descripcin de
requisitos, esto se hace mediante la
utilizacin de un prototipo.

Verificacin

Se refiere al proceso de determinar si los productos

de una determinada fase del proceso de desarrollo
de software cumplen con los requerimientos
establecidos durante la fase previa. Trata de
identificar defectos o errores que generen fallas.
Una de las tcnicas ms comunes para la
verificacin es la revisin tcnica.
Por ejemplo, una revisin de especificaciones
intenta verificar el modelo del anlisis contra la
Especificacin de Requisitos

Tipos de Productos para V&V

Requisitos
Diseo
Implementacin
Administracin de la Configuracin y
Cambios

Objetivo de la V&V

Asegurar que el producto satisface las

necesidades del usuario.
Aspectos considerados por la V&V:
{
{
{
{
{
{

Funcionalidad
Portabilidad
Desempeo
Mantenibilidad
Seguridad
Usabilidad

Clasificacin de la aplicabilidad de
las tcnicas y enfoques de V&V

Correctud
{

Consistencia
{

El grado en que lo contenido en el producto es necesario.

Suficiencia (Completud)
{

El grado en el que el producto es consistente consigo mismo y

con otros productos.

Necesidad
{

El grado en el que el producto est libre de defectos.

El grado en el que el producto est completo.

Desempeo
{

El grado en el que el producto satisface sus requisitos de

desempeo.

Enfoques y tcnicas de V&V

Revisiones Tcnicas del Software

(Recorridos e Inspecciones)
Prueba de Software
Simulacin y Prototipos
Rastreabilidad de Requisitos

Revisin Tcnica Formal (RTF)

Actividad del control de calidad del software
Objetivos:
{

Descubrir errores en la funcin, lgica o

implementacin en cualquier representacin
del software.
Verificar que el software en revisin satisface
sus requisitos
Garantizar que el software se ha representado
de acuerdo con los estndares predefinidos.

Revisin Tcnica Formal (RTF)

{

Lograr software desarrollado en una

manera uniforme.
Hacer proyectos ms manejables.

10

Revisin Tcnica Formal (RTF)

Sirve como un proceso de entrenamiento pues

permite que los ingenieros menos experimentados
observen diferentes enfoques respecto al anlisis,
el diseo y la construccin de software.

Promueve el soporte y la continuidad, pues varias

personas se familiarizan con partes del software
que de otra forma nunca veran.

Cada RTF se realiza en una junta y tendr xito si

se planifica, controla y atendiende apropiadamente.

Junta de revisin
Cualquier junta de revisin debe atenerse a las
siguientes restricciones:
{ En la revisin se deben involucrar entre 3 y 5
personas.
{ Se debe preparar con anticipacin, pero sin que
requiera ms de 2 horas de trabajo de cada
persona.
{ La duracin de la junta de revisin debe ser
menor a dos horas.
Estas restricciones implican que una RTF se enfoca en
una parte especfica y pequea del software total
(Porcin de especificacin, diseo detallado de
componente, listo de cdigo fuente. Esto tambin se le
conoce como un Recorrido

11

Participantes en la preparacin y
realizacin de la junta de revisin

El Productor
{

Es el ingeniero que ha desarrollado el artefacto.

Jefe del Proyecto

Jefe de Revisin

Es el responsable del proyecto.

Evala la disponibilidad del producto, genera copias del
material necesario y las distribuye a dos o tres revisores
para que realicen sus observaciones antes de la junta.
Revisa el producto y establece una agenda.

Revisores
{

Se familiarizan con el producto considerando entre una y

dos horas y toman sus notas.

Desarrollo de la Reunin

Uno de los revisores asume el papel de

registrador
Presentacin de la agenda por parte
del Jefe de Revisores y breve
introduccin por parte del Productor.
El Productor inicia el recorrido del
producto explicando el material.
Los Revisores exponen los problemas
que descubrieron antes de la junta.

12

Desarrollo de la Reunin

El Registrador va anotando los

problemas o errores encontrados.
Al final todos los asistentes deben
decidir si:
{

Aceptan el producto sin modificaciones

posteriores.
Rechazan el artefacto debido a errores
severos encontrados.
Aceptan el producto provisionalmente.

Desarrollo de la Reunin

Se llena documento de finalizacin

indicando la participacin y
conformidad con los hallazgos del
equipo revisor.

13

Informe de la revisin y
conservacin de registros
Un informe resumen de la revisin
responde 3 preguntas:
{
{
{

Qu se revis?
Quin lo revis?
Cules fueron los hallazgos y
conclusiones?

Directrices de la revisin

Revisar el producto, no al productor

Establecer una agenda y respetarla
Limitar el debate y la impugnacin
Enunciar reas de problemas, pero no
se intente resolver todos los que se
hayan sealado.

14

Directrices de la revisin

Tomar notas
Limitar el nmero de participantes e
insistir en la preparacin anticipada.
Desarrollar una lista de verificacin
para cada producto que tenga
probabilidad de ser revisado.

Directrices de la revisin

Asignar recursos y programar las RTF.

Realizar un entrenamiento significativo
de todos los revisores.
Analizar las revisiones previas.

15

Simulacin y Prototipos

Son tcnicas para analizar el

comportamiento esperado de un producto.
Para los propsitos de la V&V, son
normalmente utilizadas para analizar las
especificaciones de requisitos
asegurarando que reflejan las necesidades
de los usuarios.
Tambin se utilizan para analizar el
desempeo esperado del producto en
relacin a los requisitos no funcionales.

Rastreo de Requisitos

Es una tcnica para asegurar que el

producto, as como la prueba del
producto corresponden a cada uno de
sus requisitos.
El enfoque tradicional para llevarlo a
cabo es mediante el uso de matrices.

16

Garanta de la calidad estadstica

del software

La informacin acerca de los defectos de

software se recopila y clasifica.
Se intenta determinar la causa de cada
defecto
Mediante el principio de Pareto (80% de
los defectos se encuentran en 20% de
todas las causas posibles) se aisla un
20%

Garanta de la calidad
estadstica del software

Una vez que las causas vitales han

sido identificadas, se corrigen los
problemas que han provocado los
defectos.

17

Un ejemplo genrico de la aplicacin

de mtodos estadsticos

Supngase que una organizacin

recopila los defectos de un ao
{

Especificaciones incompletas o errneas

(EIE)
Mala interpretacin de la comunicacin
con el cliente (MCC)
Desviacin intencional de las
especificaciones (DIE)

Un ejemplo genrico de la aplicacin

de mtodos estadsticos
{

{
{

Violacin de los estndares de

programacin (VEP)
Errores en la representacin de los datos
(modelos de clases, datos) (ERD)
Interfaz de componente inconsistente
(ICI)
Error en la lgica del diseo (ELD)
Prueba incompleta o errnea (PIE)

18

Un ejemplo genrico de la aplicacin

de mtodos estadsticos
{

{
{

Error en la traduccin del diseo al

lenguaje de programacin (TLP)
Errores en la representacin de los datos
(modelos de clases, datos) (ERD)
Interfaz de componente inconsistente
(ICI)
Error en la lgica del diseo (ELD)
Prueba incompleta o errnea (PIE)

Datos estadsticos
Total
Error

Nmero

Serios
%

Nmero

Moderados
%

Nmero

Menores

Nmero

EIE

205

24

34

27

68

20

103

27

MCC

156

18

12

10

68

20

76

20

DIE

48

24

23

VEP

25

15

10

ERD

130

15

26

21

68

20

36

ICI

58

18

31

ELD

45

14

11

12

19

PIE

95

11

12

10

35

10

48

12

DII

36

20

14

TLP

60

15

12

19

26

858

100

125

100

347

100

386

100

Totales

19

Interpretacin sobre los

resultados presentados
La tabla indica que EIE, MCC y ERD son
las causas vitales al representar el 53%
de todos los errores. Sin embargo, se
debe observar que EIE, ERD, TLP y ELD
se seleccionaran como causas vitales si
slo se consideran errores serios.

Acciones correctivas

Para corregir EIE y MCC implementar

tcnicas que faciliciten la recopilacin
de requisitos y que a su vez mejoren
la comunicacin con el cliente.
Para mejorar ERD adquirir
herramientas para el modelado de
clases y datos y ejecutar revisiones de
diseo ms rigurosas

20

La aplicacin de SQA y el principio de

apareto pueden resumirse en una sola
oracin:
Emplee su tiempo enfocndose en las
cosas que realmente importan, !pero
primero asegrese de entender qu es lo
que realmente importa!

Referencias

Pressman, R. Ingeniera
Ed.,McGrawHill, 2006.

de

software:

un

enfoque

prctico.

6ta

21