01 Modelos y Control de Calidad

MODELOS Y CONTROL DE CALIDAD
SEMANA 1
Conceptos y herramientas
bsicas de calidad
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 1
ninguna clase.
2
ESTE DOCUMENTO CONTIENE LA SEMANA 1
NDICE
CONCEPTOS Y HERRAMIENTAS BSICAS DE CALIDAD ........................................................................ 5

OBJETIVOS ESPECFICOS ........................................................................................................................... 5
INTRODUCCIN ...................................................................................................................................... 5
1. FUNDAMENTOS DE LA CALIDAD ........................................................................................................ 6
1.1. CONCEPTO DE CALIDAD ...................................................................................................... 6
1.1.1. QUIN DEFINE LA CALIDAD?...................................................................................... 6
1.1.2. CONCEPTO DE CONTROL DE CALIDAD ........................................................................ 7
1.1.3. CONCEPTO DE CALIDAD DEL SOFTWARE .................................................................... 7
1.2. IMPORTANCIA DE LA CALIDAD ............................................................................................ 8
1.3. CALIDAD TOTAL ................................................................................................................... 9
2. MODELOS CLSICOS DE CALIDAD....................................................................................................... 9
2.1. MODELO DE CALIDAD DE MCCALL .................................................................................... 10
2.2. MODELO DE CALIDAD DE BOHM..................................................................................... 13
3. HERRAMIENTAS BSICAS DE CALIDAD.................................................................................. 16
3.1. DIAGRAMA DE FLUJO ........................................................................................................ 16
3.2. DIAGRAMA CAUSA-EFECTO............................................................................................... 17
3.3. DIAGRAMA DE PARETO ..................................................................................................... 19
3.4. DIAGRAMA DE CONTROL .................................................................................................. 21
COMENTARIO FINAL.......................................................................................................................... 23
REFERENCIAS........................................................................................................................................ 24
3
NDICE DE FIGURAS
Figura 1: Criterios para la operacin del producto ............................................................................ 11
Figura 2: Criterios para la revisin del producto ............................................................................... 12
Figura 3: Criterios para la transicin del producto ............................................................................ 12
Figura 4: Modelo de Bohm .............................................................................................................. 14
Figura 5: Comparacin entre McCall y Bohm .................................................................................. 16
Figura 6: Elementos grficos de un diagrama de flujo. ..................................................................... 16
Figura 7: Ejemplo de un diagrama de flujo ....................................................................................... 17
Figura 8: Diagrama Ishikawa (Causa-Efecto) .................................................................................... 18
Figura 9: Ejemplo de aplicacin del modelo ...................................................................................... 18
Figura 10: Variacin y detalle aplicado en el modelo........................................................................ 19
Figura 11: Categorizacin motivos de prdidas ................................................................................ 20
Figura 12: Aplicacin del principio de Pareto .................................................................................... 21
4
CONCEPTOS Y HERRAMIENTAS BSICAS DE CALIDAD
OBJETIVOS ESPECFICOS
Comprender los aspectos fundamentales del concepto de calidad y su importancia segn
la perspectiva de la calidad del software.
Comprender los modelos clsicos de calidad del software.
Utilizar las distintas herramientas bsicas de calidad en un proceso de software.
INTRODUCCIN
En general, quienes desarrollan productos o brindan servicios a terceros compiten en diferentes
mercados y focalizan sus esfuerzos en satisfacer la demanda de quienes estn dispuestos a
adquirirlos por un determinado valor econmico. En el mercado de las tecnologas de informacin,
ocurre exactamente lo mismo y, por tal razn, la calidad del producto de software se ha
transformado en un diferenciador que determina si el esfuerzo invertido realmente se capitalizar
en una solucin til y valorada en el entorno donde se utilice. Para lograrlo, es necesario entender
los conceptos que fundamentan la calidad vista desde la perspectiva del proceso de desarrollo de
software, y tambin, del producto de software como tal. Para poder realizarlo, es necesario
disponer de herramientas (tcnicas y mtodos) que faciliten la medicin y control de la calidad
durante el ciclo de desarrollo y uso posterior.
En la actualidad, existe una gran cantidad de modelos de calidad orientados a mejorar tanto el
proceso y el producto de software. En esta semana se revisarn algunos de los estndares ms
utilizados en la actualidad.
5
1. FUNDAMENTOS DE LA CALIDAD
Al referirse a calidad, se pueden encontrar bastantes definiciones en la literatura y otras fuentes
de informacin. Sin embargo, en forma natural se relaciona con una serie de caractersticas
propias que permiten identificar un mayor valor en un producto o servicio respecto a otros
similares.
Por ejemplo, si se quiere comprar un vehculo y tenemos un presupuesto acotado, se tratara de

obtener el mximo de beneficios por ese valor. Sin embargo, al no encontrar el auto ideal para el
presupuesto que se tiene, tampoco se va a querer pagar la misma cantidad por una alternativa
que no satisface plenamente lo que se espera.
Lo anterior habla de caractersticas que bien podran clasificarse como subjetivas, porque se
construyen sobre la base de percepciones y no por algn criterio medible. Siguiendo la idea del
ejemplo anterior, la percepcin de dos personas respecto a la calidad del auto puede ser distinta.
Uno puede preferir un auto desde el punto de vista funcional, y la otra persona guiarse por los
accesorios que pueda o no tener. Por tanto, la calidad vista de esa manera no necesariamente
debe ser la misma y va a depender de la informacin disponible que tenga cada uno para evaluar,
o tal vez de las expectativas que espera satisfacer.
En ambos casos el concepto es abstracto y subjetivo, por lo cual es necesario establecer criterios
sobre la base de estndares, para poder cuantificar o medir en forma objetiva el grado de
calidad en un producto o la prestacin de un servicio determinado.
1.1. CONCEPTO DE CALIDAD
1.1.1. QUIN DEFINE LA CALIDAD?
De acuerdo al Diccionario de la Real Academia Espaola1, en sus cuatro primeras acepciones, la

calidad se define como:
Propiedad o conjunto de propiedades inherentes a algo, que permiten juzgar su valor.

Buena calidad, superioridad o excelencia.
Carcter, genio, ndole.
Condicin o requisito que se pone en un contrato.
Al leer cada una de estas definiciones, podemos pensar que la segunda de ellas parece ser ms
clara que las otras, o al menos pareciera ser la ms concreta. Sin embargo, como se mencion
anteriormente, al referirnos a la calidad de un producto o servicio, resultar subjetivo
dependiendo de cmo sea evaluada. Asimismo, la primera definicin abre la posibilidad de
1
http://goo.gl/e5NvDg
6
determinar ciertos aspectos, propiedades o caractersticas que son medibles o cuantificables. Por
consiguiente, dan una idea de precisar qu aspectos se van a medir y con qu criterios se van a
hacer.
Ahora bien, cuando se desarrolla un producto de software, uno de los factores que determina su
calidad es el cumplimiento de las expectativas declaradas antes de su desarrollo. En este caso, se
puede establecer que la definicin de los requerimientos funcionales y de sistema es la que
ayudar a determinar el grado de adherencia del producto de software respecto al resultado final.
Esto es concluyente, categrico (ISO 9126-2001).
Por ejemplo, un sistema de recaudacin para las cajas de un supermercado debe ser preciso,
realizar bien los clculos, tener inventariados todos los productos y, adems, tener un tiempo de
respuesta rapidsimo. De qu servira un sistema que demora en buscar los productos y realizar
las operaciones en forma lenta? Si bien se puede llegar al mismo resultado, el impacto en la
atencin de los clientes es relevante y de inters para los administradores del supermercado. En
este caso se dir que un sistema de recaudacin es de calidad si satisface ampliamente las
necesidades de la empresa, en funcin de sus clientes.
1.1.2. CONCEPTO DE CONTROL DE CALIDAD

Anteriormente se mencion la calidad como una caracterstica de un sistema de software, la cual
puede ser medible sobre la base de criterios que se definan previamente antes de construirlo
(especificaciones funcionales y de sistema). Entonces, a lo anterior se debe incorporar tambin
otro concepto que ayude y gue a la organizacin a producir sistemas de software de calidad.
Vamos a referirnos al concepto de gestionar la calidad. Esto es, definir, planificar y ejecutar una
serie de acciones que permitan dar visibilidad al proceso de desarrollo del sistema. Por lo cual,
apoyados en algn mtodo, se realizarn mediciones que ayuden a identificar que el desarrollo del
sistema se est realizando de acuerdo a como estaba planificado. Ante cualquier desviacin,
existir la forma de detectarlo, informarlo y corregirlo. A la secuencia de estos eventos, los
podemos llamar control de calidad. Este control se realiza directamente sobre el sistema de
software, como tambin sobre todas las actividades que al ser ejecutadas le van dando forma al
producto final.
1.1.3. CONCEPTO DE CALIDAD DEL SOFTWARE

De esta forma, si se acerca la definicin de calidad al mbito de los sistemas de software, se
pueden citar las siguientes definiciones:
Concordancia de los requerimientos funcionales con los productos de desarrollo

explcitamente documentados y con las caractersticas implcitas que se espera de todo
software desarrollado profesionalmente (Pressman, 2010)
7
Grado con que un sistema, componente o proceso cumple con los requerimientos
especificados y las necesidades o expectativas del cliente o usuario (definicin sobre la base
del estndar IEEE, Std. 610-1990).
Estas definiciones sealan que para un sistema de software el concepto de calidad debe definirse
previamente para poder medirlo en forma posterior. La pregunta que se puede plantear en virtud
de lo anterior sera: quin o quines realizarn estas mediciones? La respuesta es simple: todos
los involucrados en el proceso de desarrollo del software, por ejemplo, ingenieros (analistas,
desarrolladores, testers) y usuarios.
Es importante destacar que el software tiene caractersticas especiales, las cuales se pueden citar
a continuacin (Pressman, 2010):
El software es lgico, no fsico.

El software se desarrolla, no se fabrica.
En su gran mayora es desarrollado a la medida.
Usualmente el desarrollo de software tarda ms de lo planificado, se sobrepasa el presupuesto
inicial y, usualmente, es entregado con problemas de funcionalidad.
1.2. IMPORTANCIA DE LA CALIDAD

La calidad desde el punto de vista de un proceso es relevante debido a que tiene impacto en los
tiempos y costos de desarrollo. Por ejemplo, ante un escenario donde no hay un control de calidad
slido, se puede incurrir en muchos errores. Corregirlos tiene un costo econmico y adems en el
cumplimiento de plazos. Ahora bien, cuando estos errores son detectados en etapas avanzadas del
desarrollo del sistema, resultan ms costosos aun. Imagine la obra de construccin de un edificio
de veinte pisos, el ingeniero calculista visualiza un error de clculo cuando ya han construido
quince de los veinte pisos... Es un desastre!
Por esta razn, si producto del proceso de calidad empleado baja la tasa de errores y, adems, la
solucin cumple con las expectativas definidas junto al usuario, entonces, esta forma de hacer
software puede repetirse bajando costos y asegurando el cumpliendo plazos.
Es bueno reforzar tambin que, la calidad de un producto o servicio se puede interpretar de

acuerdo a lo siguiente (p. cit.):
Ante dos productos ofrecidos al mismo precio, se elige el de mayor calidad.

Ante dos productos de la misma calidad, se elige el de menor precio.
8
1.3. CALIDAD TOTAL
Anteriormente se entregaron conceptos que definen la calidad en su amplio contexto de
aplicacin y, particularmente, en la industria del desarrollo de software. Respecto a esta, se
identifica lo siguiente:
Un proceso que gobierna el desarrollo del software (mtodos y herramientas).

Caractersticas propias del producto de software que determinan su calidad (especificaciones
funcionales y de sistema).
Sin embargo, el concepto de calidad total es mucho ms que lo anterior. Corresponde a una
estrategia corporativa que se transforma en una filosofa de hacer las cosas y su foco objetivo es la
satisfaccin del cliente. Cabe sealar respecto a esto que un cliente puede ser interno o externo a
una organizacin.
Se define como cliente interno cuando el resultado de un trabajo desarrollado por un rea
especfica es el insumo que requiere otra rea (cliente interno) para realizar sus actividades. Por
ejemplo, en una empresa de la industria bancaria, el rea comercial es un cliente interno de las
reas de apoyo, como es el rea informtica. Por qu? Porque el rea comercial requiere
informacin para preparar el lanzamiento de nuevos productos e identificar un nuevo mercado
objetivo, por nombrar algunos casos. Entonces, es el rea informtica la que provee esa
informacin (proveedor interno). Dicho lo anterior, se entiende que el cliente externo a una
organizacin es el que ya se conoce, y sobre el cual se hacen los mayores esfuerzos para satisfacer
sus requerimientos de productos o servicios.
Continuando con la idea de calidad total, se puede establecer que no se refiere solamente al
producto o servicio que desarrolla la organizacin, sino que ms bien cubre todos los aspectos y
actividades organizacionales y es transversal a las jerarquas o jefaturas. Es decir, desde un gerente
hasta el empleado de menor rango estn alineados y comprometidos con los objetivos de la
empresa, generando todos los procesos y herramientas para desarrollar un producto o servicio de
calidad para sus clientes, no solamente en lo que a software se refiere. Todos sus procesos
internos son gobernados a travs de mecanismos de calidad donde la suma de todas las partes
asegura la produccin de un producto o servicio de calidad.
2. MODELOS CLSICOS DE CALIDAD

Los modelos de calidad integran un conjunto de propiedades y mtodos que ayudan a estructurar
conceptos de este mbito, con el fin de asegurar grados de calidad en su aplicacin final. Desde la
perspectiva de la calidad en un producto de software, hay dos modelos que es necesario revisar,
dado el aporte que han significado en la evolucin del desarrollo de estos productos.
A continuacin, se presentan dos modelos de calidad, elaborados por Boehm y McCall

respectivamente.
9
2.1. MODELO DE CALIDAD DE MCCALL
El modelo de McCall describe la calidad como la integracin de relaciones jerrquicas entre
factores, criterios y mtricas
El modelo se organiza sobre la base de tres grandes conceptos, donde en cada uno de ellos se
definen factores de calidad (Piattini, Garca, Garca, Ignacio y Pino, 2012):
1) Operacin del producto:
En este mbito se consideran conceptos como, por ejemplo, facilidad de uso,

integridad, correccin, fiabilidad y eficiencia.
Los factores de calidad son los siguientes:

Facilidad de uso: cun fcil resulta utilizar el software.
Integridad: respecto a si el sistema y sus datos son seguros.
Correccin: se refiere a si el software hace lo que se requiere.
Fiabilidad: se refiere a si el software hace siempre bien lo que debe hacer.
Eficiencia: de qu manera se desempea en la plataforma de hardware que
tengo.
2) Revisin del producto:
En este mbito se consideran conceptos como, por ejemplo, facilidad de

mantenimiento, facilidad de prueba y flexibilidad.
Facilidad de mantenimiento: cun fcil resulta corregir errores o mejorarlo.
Facilidad de prueba: cun fcil resulta testearlo.
Flexibilidad: si me permite o no modificarlo.
3) Transicin del producto:
En este mbito se consideran conceptos como, por ejemplo, facilidad de reutilizacin,

interoperabilidad y portabilidad.
Facilidad de reutilizacin: si es factible reutilizar parte o todo el producto.
Interoperabilidad: cun complejo resulta comunicarlo con otros sistemas.
Portabilidad: cun complejo es migrarlo de una mquina a otra (distintas
tecnologas).
10
El concepto de calidad abarca, entonces, tres aspectos en un producto de software: (1) operacin
del producto, (2) revisin del producto y (3) transicin del producto. Y es a partir de estos
conceptos desde donde se definen las caractersticas claves que debe tener un producto de
software de calidad.
El factor de calidad se compone de una serie de atributos que se denominan criterios de calidad,
los cuales son medidos a travs de mtricas utilizadas para cuantificarlos. A continuacin se
muestra un detalle de criterios en cada uno de los factores de calidad indicados.
Figura 1: Criterios para la operacin del producto

Fuente: material elaborado para esta asignatura (J. Reyes, 2015)
11
Figura 2: Criterios para la revisin del producto
Figura 3: Criterios para la transicin del producto

Sobre la base de lo anterior, el modelo permite cuantificar la calidad del producto, haciendo lo
siguiente:
Identificacin de los factores que determinan la calidad del software

Establecer criterios de evaluacin para cada factor
Establecer mtricas para los criterios y una funcin de normalizacin que determine la
relacin entre las mtricas y los factores.
12
Evaluacin de mtricas
Correlacin de las mtricas a un conjunto de guas que cualquier equipo de desarrollo
podra seguir
Desarrollo de las recomendaciones para la coleccin de mtricas
Al iniciarse un proyecto es necesario especificar los requerimientos de calidad, seleccionando los

aspectos inherentes a la calidad deseada del producto de software.
Asimismo, considerar tambin lo siguiente:
Las caractersticas particulares del propio producto que se est diseando.

La relacin calidad vs. precio, identificando la relacin costo beneficio de cada uno de los
factores
Definir las etapas del ciclo de vida del producto, debido a que se deben evaluar los
factores de calidad elegidos por cada etapa.
La importancia o relevancia de algunos factores por sobre otros.
Adems, sindicar los valores deseables para los criterios, donde es necesario emplear datos
histricos, el promedio en la industria, con los cuales se debe establecer los valores finales y otros
intermedios o predictivos en cada perodo de medicin durante el desarrollo, as tambin, valores
mnimos aceptables.
Durante el desarrollo hay que establecer mtricas, analizar sus resultados y sensibilizar los valores
registrados. Posteriormente, finalizado el proyecto, realizar una comparacin de medidas
predictivas utilizadas y ver si se pueden tomar como indicadores de los valores finales.
2.2. MODELO DE CALIDAD DE BOHM

El modelo de Bohm se caracteriza por tener una estructura jerrquica y presentar los criterios de
calidad en tres grandes divisiones. El primero de ellos, tambin denominado de alto nivel, est en
funcin de los servicios que el sistema ofrece (portabilidad). La segunda divisin se enfoca en la
operacin del producto (usabilidad) y, por ltimo, la tercera divisin se enfoca a la mantenibilidad
del producto de software (Futrell, Shafer y Shafer, 2002).
Este modelo tiene por objeto la calidad del software, para que este:
1) Funcione como el usuario espera que lo haga

2) Sea eficiente, utilizando los recursos informticos de manera correcta
3) Su utilizacin y aprendizaje sean limpios, claros y fciles
4) Est bien diseado, codificado, probado y sea fcil de mantener.
13
Es un modelo que enriquece al de McCall, pero es muy similar, ya que posee una jerarqua de
caractersticas y se basa en un amplio rango de caractersticas. Incorpora 19 criterios que incluyen
caractersticas de performance del hardware.
A continuacin, en la Figura 4, se muestra cmo se dispone este modelo.
Caractersticas de
Utilidad, mantenimiento, portabilidad
alto nivel
Caractersticas de
Portabilidad, fiabilidad, eficiencia,
Modelo de Bohm nivel intermedio
usabilidad, capacidad de prueba,
(factores de comprensibilidad, flexibilidad
calidad)
Caractersticas Independencia, completitud, exactitud,

primitivas consistencia, eficiencia, accesibilidad,
comunicatividad, estructuracin,
autodescriptividad, concisin,
legibilidad, expansividad
Figura 4: Modelo de Bohm

Al describir el modelo de acuerdo a las divisiones que se muestran en la Figura 4, se tiene lo

siguiente:
Caractersticas de alto nivel:
Se refieren especficamente a requerimientos generales de uso.

o Portabilidad: es el esfuerzo de transportar el software a otra plataforma
o Utilidad: es el producto como tal, es confiable?, es eficiente?
o Mantenimiento: se mide la facilidad de entenderlo, modificarlo y probarlo
Segundo nivel
Representan los factores de calidad del modelo

o Confiabilidad: es una propiedad que implica el grado de confianza esperado por
parte del usuario en la operacin adecuada del sistema al utilizarlo.
o Eficiencia: se refiere al esfuerzo en base al costo de los recursos de software y
hardware que utiliza un sistema.
14
o Ingeniera social: se refiere al entendimiento y aceptacin del sistema por parte
del usuario solicitante de la solucin.
o Pruebas: corresponde al conjunto de evaluaciones que se realiza sobre el
software, una vez desarrollado. El objetivo es validar que la funcionalidad
corresponda a lo especificado previamente.
o Facilidad de entendimiento: se refiere a la claridad con que fue escrito el cdigo
fuente del software, es decir, la lgica asociada es fcil de entender.
o Entendibilidad: es la claridad de la lgica del cdigo fuente de una pieza de
software.
o Modificabilidad: este atributo del software facilita la incorporacin de
modificaciones durante la vida til del producto. Asimismo, est directamente
relacionado con el atributo de entendibilidad, debido a que si el cdigo es
entendible, podr ser modificado sin que los cambios produzcan efectos
negativos.
Tercer nivel
Son caractersticas de uno o ms factores de calidad.
El modelo tiene como finalidad verificar que el producto de software cumpla lo siguiente:
Haga lo que desea el usuario

Utilice recursos informticos de manera correcta y eficiente
Sea fcil de utilizar y aprender
Sea bien diseado, codificado, probado y mantenido
En la siguiente figura aparece una breve comparacin entre los modelos de McCall y Bohm.
15
Figura 5: Comparacin entre McCall y Bohm
Fuente: material elaborado para esta asignatura (J. Reyes, 2015).
3. HERRAMIENTAS BSICAS DE CALIDAD

3.1. DIAGRAMA DE FLUJO
Los diagramas de flujo corresponden a un mtodo grfico para representar visualmente el flujo de
datos que existe en un sistema de software. De esta forma, muestran operaciones y las secuencias
que se requieren para solucionar un problema determinado.
Dada su naturaleza, facilitan la comunicacin entre los profesionales que desarrollan el software y
aquellos que se especializan en el proceso de negocio. Idealmente se deben utilizar para
solucionar problemas complejos y extensos.
Para realizar una representacin de un problema a travs de un diagrama de flujo, ser necesario
conocer la nomenclatura que define este mtodo. Algunos de los smbolos utilizados son los
presentados en la siguiente tabla. Se sugiere investigar otros smbolos y su utilizacin.
Smbolo Descripcin Smbolo Descripcin

Inicio o fin del programa Conector para unir el
flujo a otra parte del
diagrama
Identifica un proceso Lneas de dibujo
Toma de decisin o
ramificacin ante un
evento
Figura 6: Elementos grficos de un diagrama de flujo.
Pare desarrollar un diagrama de flujo, se debieran considerar los siguientes lineamientos:
16
1) Escribirse desde arriba y hacia abajo.
2) Los smbolos se unen con lneas, las cuales tienen una flecha indicando el sentido del flujo
(idealmente trazarlas en forma vertical u horizontal).
3) Evitar el cruce de lneas, para no ensuciar el dibujo.
4) No deben quedar lneas hurfanas. Esto es, lneas de flujo sin conectar.
5) Todo texto en los smbolos debe representar un verbo (asignar, contar, validar, calcular).
6) Todo smbolo puede tener ms de una lnea de entrada, a excepcin del smbolo final.
7) Solamente los smbolos de decisin pueden tener ms de una lnea de salida (usualmente
dos).
A continuacin se presenta un ejemplo de un diagrama de flujo.
Figura 7: Ejemplo de un diagrama de flujo

3.2. DIAGRAMA CAUSA-EFECTO

Tambin conocido como diagrama de Ishikawa, porque fue creado por Kaoru Ishikawa, experto en
direccin de empresas e interesado en mejorar el control de calidad. Otros lo llaman diagrama
espina de pescado dada que su forma grfica que se asemeja al esqueleto de un pez, o bien,
diagrama de causa y efecto.
17
Este diagrama se usa para mostrar la relacin entre distintos factores que pueden llegar a
determinar un evento determinado. Idealmente se sugiere su utilizacin para analizar y discutir
entre varios participantes una problemtica determinada.
La forma de representacin de este diagrama es con un rectngulo (cabeza) ubicado a la derecha

del diagrama, una lnea horizontal (columna vertebral) que apunta al rectngulo y sobre esta (la
lnea) convergen una serie de lneas (espinas) que van representando informacin (causas) de
inters para el anlisis del problema.
Figura 8: Diagrama Ishikawa (Causa-Efecto)

Por ejemplo, revise la siguiente situacin, en que una empresa forestal analiza las principales
causas y efectos en su modelo productivo para poder mitigar los daos ambientales que se
desprenden de su funcionamiento y que, por cierto, provocan un problema legal segn las normas
ambientales vigentes.
Figura 9: Ejemplo de aplicacin del modelo

18
En el ejemplo anterior, las causas principales que se analizan corresponden a la maquinaria
utilizada, los procedimientos productivos que se utilizan, los controles internos vigentes y la
calidad de los materiales que se utilizan. Tambin se podran considerar causas secundarias, por
ejemplo, las siguientes:
Mantenimiento
Figura 10: Variacin y detalle aplicado en el modelo

Al analizar los aspectos asociados al uso de maquinaria, hay varios temas que considerar. Uno de
ellos sera revisar si la poltica actual para el mantenimiento es la adecuada segn las normas
medioambientales vigentes.
De esta forma, si se revisaran cada una de ellas, se lograra establecer un mapa de causas y
efectos, los cuales podran ser modificados (en este caso atendiendo las causas) para mejorar
aquello que es exigido por las leyes ambientales, evitando las demandas, multas y acciones que se
desprenden al no ser cumplidas.
3.3. DIAGRAMA DE PARETO

El diagrama permite detectar los problemas que tienen mayor importancia mediante la aplicacin
del principio de Vilfredo Pareto (1923), el cual define que, por lo general, el 80% de los resultados
totales se originan en el 20% de los elementos. Es una herramienta utilizada para priorizar los
problemas o las causas que los generan. Segn este concepto, si se tiene un problema con muchas
causas, podemos decir que el 20% de ellas resuelven el 80% del problema y el 80% de las
causas solo resuelven el 20% del problema.
Es importante notar que la utilizacin de este principio es aplicable a lo siguiente:
Identificar el o los principales factores de un problema.

Determinar el factor ms importante de un problema.
Identificar el objeto de mejora y qu aspectos de este se pueden mejorar.
Analizar posteriormente a su aplicacin, el efecto de las medidas tomadas para corregirlo.
19
Para aplicar este principio, se deben ejecutar las siguientes actividades:
a) Recoleccin de datos asociados a una problemtica que se est analizando, tratando de

identificar grupos o categoras de datos.
b) Contabilizar por cada categora el nmero de ocurrencias que muestra el universo de
datos seleccionado.
c) Asignar porcentajes a cada categora.
d) Construir una grfica con la informacin analizada y los clculos de porcentajes obtenidos.
Un ejemplo sencillo:
En una planta de produccin industrial han ocurrido una serie de interrupciones, las cuales
obedecen a una serie de eventos no deseados. Luego de hacer un registro estadstico de estos, se
obtuvo la siguiente tabla de datos, los cuales se presentan en la Figura 10.
Figura 11: Categorizacin motivos de prdidas

Las categoras de eventos se muestran en la columna prdida. La frecuencia de cada uno de ellos
es presentada en la columna frecuencia. Asimismo, en la columna %Total, se muestra el
porcentaje asociado a cada evento, mientras que en la columna %Acumulado se suma cada uno de
los porcentajes indicados para cada evento.
Al llevar la informacin a un grfico construido con la herramienta Microsoft Excel, se obtuvo lo

siguiente:
20
Aplicacin principio de Pareto
Figura 12: Aplicacin del principio de Pareto

Si se considera como punto de quiebre un 70% del acumulado (ver el crculo rojo), se puede
establecer que la principal causa de las prdidas en la produccin es el fallo de UPS, microcortes y
cada de sistemas, que es donde se debiera invertir el esfuerzo para mejorar el proceso
productivo.
3.4. DIAGRAMA DE CONTROL

Es un mtodo de control estadstico enfocado en el proceso productivo, el cual ayuda a identificar
cuando este se encuentra fuera de los rangos en los cuales debiera comportarse. Es una
herramienta simple, que permite ser utilizada en forma sencilla, dada la disposicin que refleja
una lnea central con dos lmites, uno inferior y otro superior. As, cuando las entradas que genera
el resultado de la lnea productiva escapan a uno de los dos lmites establecidos (inferior o
superior), se levantan las alertas para analizar y atender las necesidades del proceso para su
normalizacin.
El proceso se encuentra bajo control estadstico cuando se producen variaciones por motivos
aleatorios. Mientras que el proceso se encuentra fuera del proceso estadstico cuando las
variaciones son producto de motivos no aleatorios.
De cada proceso que se requiere medir es necesario registrar muestras peridicas de una o ms
variables de anlisis. De estas ltimas, se registra un porcentaje de las piezas con fallas en el
intervalo de tiempo definido. Por ejemplo, mediciones cada 6 horas registran 3 piezas con fallas
21
usualmente. En este caso se debe considerar el lapso de tiempo y la cantidad total de piezas
monitoreadas en ese perodo.
Ajustando estas definiciones a la produccin de software, las piezas con fallas corresponderan,
por ejemplo, a las piezas de software que registran errores en su etapa de desarrollo, antes de
pasarlas a la etapa de pruebas o testing. Asimismo, una vez puestas en la etapa de pruebas, se
puede precisar otro tipo de mediciones.
Al igual que las anteriores herramientas, el grfico estadstico permite identificar una tendencia y
sobre esa base ajustar para mejorar los procesos. Por ejemplo, si en la etapa de desarrollo se
considera aceptable diez errores de programacin por programa, si se quisiera mejorar aun ms,
se podra establecer que el mximo nmero de errores fuera cinco, y medirlos posteriormente,
habiendo atendido tambin las causas que los generaban.
22
COMENTARIO FINAL
La calidad en la produccin de software es de vital importancia, dado que ayuda a las empresas a
cumplir con fluidez sus objetivos estratgicos, maximizar el costo de sus inversiones en la
implantacin de nuevos sistemas, mejorar el apoyo a las reas en el desempeo de sus funciones,
brindar mejor atencin a sus clientes finales y disponer en forma oportuna de la informacin
necesaria para la mejor gestin y planificacin de los recursos.
El contenido de esta semana entrega una visin del concepto de calidad del software que se debe
aplicar en las organizaciones que lo utilizan para mejorar la productividad en sus procesos de
negocio especficos.
23
REFERENCIAS
Piattini, M.; Garca F.; Garca, I. y Pino, F. (2012). Calidad de sistemas de informacin. Mxico:
Alfaomega Grupo Editor S. A.
Fernndez de Velasco, J. (2013). Gestin por procesos. Espaa: ESIC Editorial.
International Organization for Standardization. (2001). ISO 9126 Software engineering. Ginebra,
Suiza: ISO.
IEEE Computer Society (s.f.). About SWEBOK. Recuperado de: http://goo.gl/MkwRbX
Pressman, R. (2010). Ingeniera de software, un enfoque prctico. 7.a ed. Espaa: McGraw Hill
Interamericana S. A.
Futrell, R.; Shafer, D. y Shafer, L. (2002). Quality Software Project Management. EE.UU.: Prentice
Hall.
PARA REFERENCIAR ESTE DOCUMENTO, CONSIDERE:
IACC (2015). Conceptos y herramientas bsicas de calidad. Modelos y Control de Calidad. Semana
1.
24
25

01 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

01 Modelos y Control de Calidad

Uploaded by

Copyright:

Available Formats

MODELOS Y CONTROL DE CALIDAD

CONCEPTOS Y HERRAMIENTAS BSICAS DE CALIDAD ........................................................................ 5

Por ejemplo, si se quiere comprar un vehculo y tenemos un presupuesto acotado, se tratara de

1.1. CONCEPTO DE CALIDAD

1.1.1. QUIN DEFINE LA CALIDAD?

De acuerdo al Diccionario de la Real Academia Espaola1, en sus cuatro primeras acepciones, la

Propiedad o conjunto de propiedades inherentes a algo, que permiten juzgar su valor.

1.1.2. CONCEPTO DE CONTROL DE CALIDAD

1.1.3. CONCEPTO DE CALIDAD DEL SOFTWARE

Concordancia de los requerimientos funcionales con los productos de desarrollo

El software es lgico, no fsico.

1.2. IMPORTANCIA DE LA CALIDAD

Es bueno reforzar tambin que, la calidad de un producto o servicio se puede interpretar de

Ante dos productos ofrecidos al mismo precio, se elige el de mayor calidad.

Un proceso que gobierna el desarrollo del software (mtodos y herramientas).

2. MODELOS CLSICOS DE CALIDAD

A continuacin, se presentan dos modelos de calidad, elaborados por Boehm y McCall

1) Operacin del producto:

En este mbito se consideran conceptos como, por ejemplo, facilidad de uso,

Los factores de calidad son los siguientes:

2) Revisin del producto:

En este mbito se consideran conceptos como, por ejemplo, facilidad de

3) Transicin del producto:

En este mbito se consideran conceptos como, por ejemplo, facilidad de reutilizacin,

Figura 1: Criterios para la operacin del producto

Figura 3: Criterios para la transicin del producto

Identificacin de los factores que determinan la calidad del software

Al iniciarse un proyecto es necesario especificar los requerimientos de calidad, seleccionando los

Asimismo, considerar tambin lo siguiente:

Las caractersticas particulares del propio producto que se est diseando.

2.2. MODELO DE CALIDAD DE BOHM

1) Funcione como el usuario espera que lo haga

A continuacin, en la Figura 4, se muestra cmo se dispone este modelo.

Caractersticas Independencia, completitud, exactitud,

Figura 4: Modelo de Bohm

Al describir el modelo de acuerdo a las divisiones que se muestran en la Figura 4, se tiene lo

Caractersticas de alto nivel:

Se refieren especficamente a requerimientos generales de uso.

Representan los factores de calidad del modelo

Son caractersticas de uno o ms factores de calidad.

Haga lo que desea el usuario

3. HERRAMIENTAS BSICAS DE CALIDAD

Smbolo Descripcin Smbolo Descripcin

Pare desarrollar un diagrama de flujo, se debieran considerar los siguientes lineamientos:

A continuacin se presenta un ejemplo de un diagrama de flujo.

Figura 7: Ejemplo de un diagrama de flujo

3.2. DIAGRAMA CAUSA-EFECTO

La forma de representacin de este diagrama es con un rectngulo (cabeza) ubicado a la derecha

Figura 8: Diagrama Ishikawa (Causa-Efecto)

Figura 9: Ejemplo de aplicacin del modelo

Figura 10: Variacin y detalle aplicado en el modelo

3.3. DIAGRAMA DE PARETO

Es importante notar que la utilizacin de este principio es aplicable a lo siguiente:

Identificar el o los principales factores de un problema.

a) Recoleccin de datos asociados a una problemtica que se est analizando, tratando de

Figura 11: Categorizacin motivos de prdidas

Al llevar la informacin a un grfico construido con la herramienta Microsoft Excel, se obtuvo lo

Figura 12: Aplicacin del principio de Pareto

3.4. DIAGRAMA DE CONTROL

Alfaomega Grupo Editor S. A.

Fernndez de Velasco, J. (2013). Gestin por procesos. Espaa: ESIC Editorial.

IEEE Computer Society (s.f.). About SWEBOK. Recuperado de: http://goo.gl/MkwRbX

PARA REFERENCIAR ESTE DOCUMENTO, CONSIDERE:

You might also like