Está en la página 1de 5

Gestin de la Calidad

Willy Duval Quezada Chvez - Wayner Xavier Bustamante


wdquezada@utpl.edu.ec - wxbustamante@utpl.edu.ec
Universidad Tcnica Particular de Loja
Escuela de Ciencias de la Computacin

1. Resumen:

Refirindose a un atributo como la


caractersticas mesurables de algo (cosas q
se pueden comparar para conocer
estndares).

El desarrollo de software es una tarea ardua


e involucra varios factores uno de ellos es la
calidad del mismo la cual si bien es relativa
desde el punto de vista de cada persona,
cumple un papel preponderante en el
momento de desarrollar un sistema, de all
que nace la gestin de la calidad del
software la cual es una actividad que
involucra el control como el aseguramiento
de la calidad la cual se lleva a cabo en cada
paso del proceso del software.
En el presente trabajo se detalla cada uno de
los pasos de la gestin de la calidad as
como el rol que cumple cada uno de los que
llevan a cabo esta tarea, y la forma como se
debe realizar un plan de gestin de calidad
para as tener producto con calidad.
2. Introduccin:
La alta necesidad de productos con calidad
ha hecho que esta sea un factor
preponderante a la hora de llevar a cabo un
proceso de software que cumpla con
estndares o normas que permitan
garantizar que nuestro producto sea capaz
de satisfacer las necesidades de nuestros
usuarios. Esto nos ha permitido llevar a cabo
un estudio sistemtico de cada uno de los
factores que involucran el desarrollo de un
software de calidad.

Seala tambin que se la puede clasificar en


2 tipos:
C. Diseo: caractersticas que los
diseadores
especifican
para
un
elemento.
C. Concordancia: Grado en el que las
especificaciones de diseo se aplican
durante la fabricacin.
Concordancia con los requisitos funcionales y
de rendimiento explcitamente establecidos con
los estndares de desarrollo explcitamente
documentados y con las caractersticas
implcitas que se espera de todo software
desarrollado profesionalmente R.S. Pressman
(1992)2.
El conjunto de caractersticas de una entidad
que le confieren su aptitud para satisfacer las
necesidades expresadas y las implcitas ISO
8402 (UNE 66-001-92)3.
Luego de haber definido la calidad podemos abordar
la gestin de calidad tambin llamada garanta de la
calidad la cual es una actividad protectora que se
aplica a lo largo de un proceso del software la cual
abarca actividades como:

3. Desarrollo:

Proceso de garanta de la calidad del


software (SQA).
Tareas especificas de aseguramiento de la
calidad del software (revisiones tcnicas
formales, estrategias de pruebas).
Practicas efectivas de ingeniera del software
(mtodos y herramientas).

Para el desarrollo de este tema inicialmente


abordaremos algunos conceptos de la
calidad para lo cual hemos citado a algunos
autores que la definen as:
El American Heritage Dictionary define a la
calidad como una caracterstica o atributo de
algo1.

Juan Manuel Cueva Lovelle, Calidad de software.pdf,


pag 3
3
Juan Manuel Cueva Lovelle, Calidad de software.pdf,
pag 3
2

American Heritage Dictionary: PRESSMAN ROGER,


Ingeniera de software, (VI edicin) .
1

Control de todos los productos de trabajo del


software.
Procedimiento
para
garantizar
los
estndares de desarrollo.
Mecanismos de medicin e informes.
La GC es una actividad que debe ser realizada por
todos y cada una de las personas involucradas en el
desarrollo del proyecto como son: Gerentes de
proyecto, desarrolladores, testers, QAs, clientes,
vendedores, etc.
El producto obtenido del proceso es un Plan de
aseguramiento de la calidad del software el cual
permitir definir la estrategia SQA del equipo del
software.
La GC es importante porque permite reducir la
cantidad de reelaboracin que se debe realizar,
reduciendo de esta manera los costos y sobre todo
mejora el tiempo de llegada al mercado.
Para la bsqueda de la calidad se debe tener en
cuenta principios como:
1.
2.
3.
4.
5.
6.
7.

Enfoque al cliente.
Liderazgo.
Participacin del personal.
Enfoque basado en proceso.
Enfoque de sistema para la gestin.
Mejora continua.
Enfoque basado en hechos para la toma
de decisiones.
8. Relaciones mutuamente beneficiosas
con el proveedor.
Estos principios corresponden a las normas ISO
9002:2000 e ISO 9004:20004
Actividades de SQA:

Independientemente de las obligaciones antes


mencionadas un grupo de SQA se encarga de:
Preparar un plan de SQA para un proyecto.
(elaborado en la fase de planificacin y
revisado por todos).
Participar en el desarrollo de la descripcin
del proceso de software del proyecto.
Revisar las actividades de ingeniera del
software para verificar que se ajuste al
proceso de software definido.
Auditar productos de trabajo de software
seleccionados para verificar que se ajusten
con los definidos como parte del proceso.
Garantiza que las desviaciones en el trabajo
de SW y en los productos de trabajo estn
documentadas.
Registra cualquier falta de ajuste y lo informa
al gestor ejecutivo.
Revisiones del software:
Las revisiones de software son un filtro para el
proceso de software es decir las revisiones se
aplican en diferentes puntos y sirven para descubrir
errores y defectos que luego pueden eliminarse.
Las revisiones purifican las actividades del
software como son Anlisis, diseo y codificacin.
Existen diferentes tipos
informales o formales.

de

revisiones

como

Las revisiones informales son aquellas que no


necesitan de una planificacin anticipada y se las
realiza de una forma informal como es el tratar o
abordar un problema en una conversacin en torno a
una mesa bebiendo un caf.

El grupo de SQA juega un rol vital dentro de la


garanta de calidad del software ya que funciona
como el representante en casa del cliente es decir
que las personas de este grupo deben ver el
software desde el punto de vista del cliente por lo
cual estn en la responsabilidad de:

Por otro lado existen las revisiones tcnicas formales


(a veces llamadas tambin comprobacin manual de
cdigo) o inspeccin las cuales abordaremos ms
adelante.

Planificar
Supervisar
Guardar registros
Analizar y reportar la garanta de la
calidad

Varios estudios realizados por TRW, NEC y Mitre


Corp., entre otros indican que en las actividades de
diseo se introducen entre el 50 a 65 por ciento de
los errores. Para ilustrar el impacto en el costo de la
deteccin temprana de errores se ha considerado
una serie de costos relativos fundamentados en
costos reales de varios proyectos los cuales sealan:

Adems de tener la misin de auxiliar al grupo de


software a conseguir un producto final de alta
calidad.

Calidad.pdf, Principios de la gestion de la calidad

Impacto de los defectos del software en el costo

Si un error es descubierto en una etapa de diseo


dicho error costara 1.0 unidades.

Si este es descubierto antes de la fase de pruebas


costara 6.5 unidades, durante las pruebas 15
unidades y luego de su liberacin entre 60 y 100
unidades.
Amplificacin y eliminacin del defecto
Para ilustrar este punto utilizaremos un modelo de
amplificacin del defecto desarrollado por [IBM] el
cual se resume en la siguiente figura:

En la figura de la izquierda se ilustra una


amplificacin con revisiones en donde se lleva a
cabo una revisin en la etapa de diseo y del cdigo,
En este caso 10 errores inciales se ampliaron a 24
antes de comenzar la etapa de pruebas y solo existe
tres errores latentes al final.
Por otro lado est la amplificacin de errores sin
revisiones En la figura inicialmente se introducen 10
errores los cuales se amplificaron a 94 en una etapa
previa a las pruebas y resulto que al final se
liberaron 12 errores latentes.
Revisiones Tcnicas Formales:

Fig1

Este representa un paso de desarrollo de software,


durante este los errores se pueden generar de forma
inadvertida, la revisin puede fallar en la deteccin
de errores generados recientemente y errores de
fases anteriores, estos ltimos se pueden amplificar
con el trabajo actual en la siguientes figuras se
ilustrar las dos dimensiones del impacto con
revisiones y sin revisiones.

Son un filtro ms efectivo desde el punto de vista de


asegurar la calidad, est dirigida por ingenieros del
software, su objetivo principal es descubrir errores
en o durante el proceso, estas permiten verificar que
el software satisface sus requisitos, garantizar que el
software se ha representado de acuerdo con los
estndares logrando un software desarrollado
uniformemente y haciendo
proyectos ms
manejables dndonos un beneficio de la no
propagacin de errores.
Quien realiza estas revisiones es la junta de
revisiones la cual est compuesta por 3 o 5 personas
del equipo de desarrollo la cual luego de la junta los
asistentes deben decidir si:
Aceptan el producto sin modificaciones
posteriores.
Rechazan el producto debido a errores
severos.
Aceptan el producto provisionalmente.

Amplificacin con revisiones


Fig2a

Se debe tener en cuenta lo siguiente durante una


junta: Qu se reviso, Quin lo reviso y cules fueron
los hallazgos y conclusiones a las que llego la junta.
Una revisin tcnica
siguientes directrices:

Amplificacin sin revisiones


Fig2b

: PRESSMAN ROGER, Ingeniera de software,


(VI edicin) .
ig2a
: PRESSMAN ROGER, Ingeniera de software,
(VI edicin) .
ig2b
PRESSMAN ROGER, Ingeniera de software,
(VI edicin) .

ig1

formal

debe

seguir

las

Revisar al producto no al productor.


Establecer una agenda y respetarla.
Limitar el debate y la impugnacin.
Enunciar reas del problema.
Tomar notas.
Limitar el nmero de participantes e insistir
en la preparacin anticipada.
Desarrollar una lista de verificacin para
cada producto que tenga la probabilidad de
ser revisado.
Asignar recursos y programar las RTF.
Realizar un entrenamiento significativo a
todos los revisores.
Analizar las revisiones previas.

Revisiones Basadas en muestras:


Puesto que en los proyectos de software los
recursos son limitados y el tiempo es corto las
RTF se soslayan, es ah donde entran en funcin
las RBM las cuales se basan en muestras de
todos los productos. Es decir el anlisis de
diferentes mdulos para poder determinar cul
de estos o en cul de estos enfocar las RTF
permitiendo de esta manera enfocarnos en
producto y bajando por ende los costos de
tiempo y recursos que implican el hacer una
revisin tcnica formal
Para que un proceso basado en muestras sea
eficaz se debe tener en cuenta:
La muestra debe ser lo suficientemente
representativa del producto de trabajo como
un todo.
Debe ser lo suficientemente grande de tal
manera que sea significativa para los
revisores que realizan el muestreo.
Enfoques formales acerca de SQA:

Una vez identificadas las causas vitales, se


corrigen los problemas que han provocado
los defectos.
Este concepto representa un paso importante hacia
la creacin de un proceso de software adaptable en
el que los cambios se hagan para mejorar aquellos
elementos que introducen errores.
Seis Sigma:
Esta es la estrategia ms ampliamente aplicada en
la actualidad para el aseguramiento estadstico de la
calidad en la industria. Popularizada por Motorola en
1980 esta es una metodologa rigurosa y disciplinada
que utiliza el anlisis de datos y estadsticos para
medir y mejorar el desempeo de una organizacin
permitiendo identificar y eliminar los defectos de
fabricacin.
Su nombre se deriva de seis desviaciones estndar
y define tres pasos centrales que son:
Definir
los
Requisitos
del
Cliente,
entregables y metas del proyecto.
Medir el proceso existente y su salida
(desempeo calidad)
Analizar las mtricas de defecto.

Nace hace dos dcadas atrs y enuncia que un


programa de computadora es un objeto matemtico
ya que en cada lenguaje se define una sintaxis y
semntica rigurosas lo que obliga a tener un enfoque
riguroso del software respecto de los requisitos de
esta manera se dice que si el lenguaje como el
modelo de requisitos es riguroso es factible de
aplicar pruebas matemticas de exactitud para
demostrar que un producto de software concuerda
exactamente con sus especificaciones.

Si es el caso en el que un proceso de software est


en marcha (requiere mejora) se aaden dos pasos
ms:

Muchos han sustentado esta idea de probar la


exactitud de los programas con sus especificaciones
como es el caso de Dijktra y Linger, Mills y Witt
entre otros quienes aconsejaron pruebas de
exactitud y los vincularon con la programacin
estructurada.

Los anteriores pasos anteriormente mencionados se


conocen como DMAMC (Definir, Medir, Analizar,
Mejorar, Controlar)

Garanta de la calidad estadstica del software:


Este tipo de garanta permite reflejar una tendencia
creciente por adoptar un enfoque ms cuantitativo
acerca de la calidad, para el software este tipo de
garanta implica los siguientes pasos:
La informacin acerca de defectos de SW se
recopila y clasifica.
Determinar la causa de cada defecto (error
de diseo).
Principio de Pareto (80% defectos se
encuentran en el 20% de las causas
posibles) se asla un 20% (vitales).

Mejorar el proceso eliminando las causas


originales de los defectos.
Controlar el proceso para garantizar que no
se repitan las causas de defectos.

Si la organizacin est desarrollando software en


lugar de mejorar el proceso los pasos centrales se
aumentan as:
Disear proceso para:
Evitar causas originales de defectos.
Satisfacer los requisitos del cliente.
Verificar el modelo del proceso.
A esta variacin se la denomina tambin DMADV
(Definir, Medir, Analizar, Disear y verificar).
Fiabilidad del Software:

La fiabilidad es un factor de calidad que a diferencia


de los otros factores es factible de medicin a partir
de datos histricos y de desarrollo.
Permitindonos definir la misma como la
probabilidad de la operacin libre de fallas de un
programa de computadora en un entorno especifico
durante un tiempo especifico.
Ha habido debates acerca de la relacin de la
fiabilidad del software con el hardware aunque se
debe reconocer que entre estos dos existe un
vnculo irrefutable.

La adopcin de modelos de control de


amplificacin de errores es fundamental para
disminuir defectos en un producto final.
Se debe realizar control de calidad desde la
etapa inicial de un proyecto y seguir este en
cada una de las etapas del mismo.
La adopcin de un plan de SQA permite
tener una gua de cmo estructurar nuestros
controles en cada etapa de construccin
permitindonos determinar qu tipo de
pruebas es mejor adoptar para nuestro
proyecto.

El plan SQA:

5. Referencias:

Esta es una herramienta que permite instituir la


garanta de seguridad del software, desarrollado por
el grupo de SQA este proporciona un plantilla de
actividades que se deberan instituir en cada
proyecto de desarrollo de software. Dentro de esta
plantilla se debe tener en cuenta lo siguiente:
1. El propsito y mbito del plan.
2. Una descripcin de todos los productos de
software.
3. Estndares y prcticas aplicables a nuestro
proceso.
4. Las acciones y tareas del SQA.
5. Las herramientas y mtodos utilizados.
6. Procedimientos de gestin de configuracin.
7. Mtodos para salvaguardar, ensamblar y
mantener los registros.
8. Documentacin,
papeles
y
responsabilidades en la organizacin
relativas a la calidad del producto elaborado.
4. Conclusiones:
Luego del anlisis del trabajo anteriormente
expuesto hemos podido concluir que la
gestin de calidad del software es uno de los
procesos ms importantes en el desarrollo
de software de calidad, ya que permite al
grupo tener o contar con una herramienta
que garantice que su trabajo cumple con
estndares de calidad como son ISO 9002 e
ISO9004.
La calidad conlleva un comprometimiento y
trabajo consiente de cada uno de los
inmersos dentro del desarrollo de un
producto de software.
El costo en tiempo y recursos es oh puede
ser regulado con la aplicacin de una cultura
de planificacin, control y garanta de
calidad.
Dentro de un producto en desarrollo es vital
la ayuda y aporte del grupo de SQA para
garantizar la construccin de un producto de
Calidad.

PRESSMAN
ROGER,
Ingeniera
de
software, (VI edicin).
SOMMERVILLE IAM (2005) Ingeniera de
Software. (VII edicin) Madrid: Ed.Pearson.
The American Heritage Dictionary of the
English Language, 3rd ed. Boston: Houghton
Mifflin Company, 1992.
International
Organization
for
Standardization (ISO/IEC) Guide 2. Geneva:
ISO Press, 1996.
Calidad del Software Conferencia, 21 de
Octubre de 1999. Grupo GIDIS Universidad
Nacional de la Pampa.
S. H. Kan. Metrics and Models in software
Quality Engineering. Addison-Wesley (1995).
Oskarsson , Glass R.L. An ISO 9000
approach to building. Quality Software.
Prentice-Hall (1996).
M.G. Piattini, J.A. Calvo-Manzano, J.
Cerveza, y L. Fernndez. Anlisis y diseo
detallado de aplicaciones informticas de
gestin. RA-MA (1996).

También podría gustarte