Contenido 01 Modelos y Control de Calidad

MODELOS Y CONTROL DE CALIDAD
SEMANA 1
Conceptos y herramientas
básicas 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 disposición del público ni 1
ESTE DOCUMENTO CONTIENE LA SEMANA 1
utilizar los contenidos para fines comerciales de ninguna clase.
2
ÍNDICE
CONCEPTOS Y HERRAMIENTAS BÁSICAS DE CALIDAD ........................................................................ 5

OBJETIVOS ESPECÍFICOS ...................................................................................................................... 5
INTRODUCCIÓN ................................................................................................................................... 5
1. FUNDAMENTOS DE LA CALIDAD .................................................................................................. 6
1.1. CONCEPTO DE CALIDAD....................................................................................................... 6
1.1.1. ¿QUIÉN 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 CLÁSICOS DE CALIDAD................................................................................................ 9
2.1. MODELO DE CALIDAD DE MCCALL .................................................................................... 10
2.2. MODELO DE CALIDAD DE BOËHM ..................................................................................... 13
3. HERRAMIENTAS BÁSICAS 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 operación del producto ............................................................................ 11
Figura 2: Criterios para la revisión del producto ............................................................................... 12
Figura 3: Criterios para la transición del producto ............................................................................ 12
Figura 4: Modelo de Boëhm .............................................................................................................. 14
Figura 5: Comparación entre McCall y Boëhm .................................................................................. 16
Figura 6: Elementos gráficos 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 aplicación del modelo ...................................................................................... 18
Figura 10: Variación y detalle aplicado en el modelo........................................................................ 19
Figura 11: Categorización motivos de pérdidas ................................................................................ 20
Figura 12: Aplicación del principio de Pareto .................................................................................... 21
4
CONCEPTOS Y HERRAMIENTAS BÁSICAS DE CALIDAD
OBJETIVOS ESPECÍFICOS
 Comprender los aspectos fundamentales del concepto de calidad y su importancia según
 la perspectiva de la calidad del software.
  Comprender los modelos clásicos de calidad del software.
 Utilizar las distintas herramientas básicas de calidad en un proceso de software.
INTRODUCCIÓN
En general, quienes desarrollan productos o brindan servicios a terceros compiten en diferentes
mercados y focalizan sus esfuerzos en satisfacer la demanda de quienes están dispuestos a
adquirirlos por un determinado valor económico. En el mercado de las tecnologías de información,
ocurre exactamente lo mismo y, por tal razón, la calidad del producto de software se ha
transformado en un diferenciador que determina si el esfuerzo invertido realmente se capitalizará
en una solución ú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 también, del producto de software como tal. Para poder realizarlo, es necesario
disponer de herramientas (técnicas y métodos) que faciliten la medición 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 revisarán algunos de los estándares más
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 información. Sin embargo, en forma natural se relaciona con una serie de características
propias que permiten identificar un mayor valor en un producto o servicio respecto a otros
similares.
Por ejemplo, si se quiere comprar un vehículo y tenemos un presupuesto acotado, se tratara de

obtener el máximo 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 características que bien podrían clasificarse como subjetivas, porque se
construyen sobre la base de percepciones y no por algún criterio medible. Siguiendo la idea del
ejemplo anterior, la percepción 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 información 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 estándares, para poder cuantificar o medir en forma objetiva el “grado de
calidad” en un producto o la prestación de un servicio determinado.
1.1. CONCEPTO DE CALIDAD
1.1.1. ¿QUIÉN DEFINE LA CALIDAD?

1
De acuerdo al Diccionario de la Real Academia Española , 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”.
  “Carácter, genio, índole”.
 “Condición o requisito que se pone en un contrato”.
Al leer cada una de estas definiciones, podemos pensar que la segunda de ellas parece ser más
clara que las otras, o al menos pareciera ser la más concreta. Sin embargo, como se mencionó
anteriormente, al referirnos a la calidad de un producto o servicio, resultará subjetivo
dependiendo de cómo sea evaluada. Asimismo, la primera definición abre la posibilidad de
1 http://goo.gl/e5NvDg
6
determinar ciertos aspectos, propiedades o características 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 definición 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, categórico (ISO 9126-2001).
Por ejemplo, un sistema de recaudación para las cajas de un supermercado debe ser preciso,
realizar bien los cálculos, tener inventariados todos los productos y, además, tener un tiempo de
respuesta rapidísimo. ¿De qué serviría 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
atención de los clientes es relevante y de interés para los administradores del supermercado. En
este caso se dirá que un sistema de recaudación es de calidad si satisface ampliamente las
necesidades de la empresa, en función de sus clientes.
1.1.2. CONCEPTO DE CONTROL DE CALIDAD
Anteriormente se mencionó la calidad como una característica 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 también
otro concepto que ayude y guíe a la organización 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 algún método, se realizarán mediciones que ayuden a identificar que el desarrollo del
sistema se está realizando de acuerdo a como estaba planificado. Ante cualquier desviación,
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 también 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 definición 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

explícitamente documentados y con las características implícitas 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 (definición sobre la base
del estándar IEEE, Std. 610-1990).
Estas definiciones señalan 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 sería: ¿quién o quiénes realizarán 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 características especiales, las cuales se pueden citar
a continuación (Pressman, 2010):
  El software es lógico, no físico.

  El software se desarrolla, no se fabrica.
 En su gran mayoría es desarrollado a la medida.

 Usualmente el desarrollo de software tarda más 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
sólido, se puede incurrir en muchos errores. Corregirlos tiene un costo económico y además en el
cumplimiento de plazos. Ahora bien, cuando estos errores son detectados en etapas avanzadas del
desarrollo del sistema, resultan más costosos aun. Imagine la obra de construcción de un edificio
de veinte pisos, el ingeniero calculista visualiza un error de cálculo cuando ya han construido
quince de los veinte pisos... ¡Es un desastre!
Por esta razón, si producto del proceso de calidad empleado baja la tasa de errores y, además, la
solución 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 también 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

aplicación y, particularmente, en la industria del desarrollo de software. Respecto a esta, se
identifica lo siguiente:
  Un proceso que gobierna el desarrollo del software (métodos y herramientas).

 Características propias del producto de software que determinan su calidad (especificaciones
funcionales y de sistema).
Sin embargo, el concepto de calidad total es mucho más que lo anterior. Corresponde a una
estrategia corporativa que se transforma en una filosofía de hacer las cosas y su foco objetivo es la
satisfacción del cliente. Cabe señalar respecto a esto que un cliente puede ser interno o externo a
una organización.
Se define como cliente interno cuando el resultado de un trabajo desarrollado por un área
específica 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 informática. ¿Por qué? Porque el área comercial requiere
información para preparar el lanzamiento de nuevos productos e identificar un nuevo mercado
objetivo, por nombrar algunos casos. Entonces, es el área informática la que provee esa
información (proveedor interno). Dicho lo anterior, se entiende que el cliente externo a una
organización 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 organización, sino que más bien cubre todos los aspectos y
actividades organizacionales y es transversal a las jerarquías o jefaturas. Es decir, desde un gerente
hasta el empleado de menor rango están 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 través de mecanismos de calidad donde la suma de todas las partes
asegura la producción de un producto o servicio de calidad.
2. MODELOS CLÁSICOS DE CALIDAD

Los modelos de calidad integran un conjunto de propiedades y métodos que ayudan a estructurar
conceptos de este ámbito, con el fin de asegurar grados de calidad en su aplicación 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 evolución del desarrollo de estos productos.
A continuación, 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 integración de relaciones jerárquicas entre
factores, criterios y métricas
El modelo se organiza sobre la base de tres grandes conceptos, donde en cada uno de ellos se
definen factores de calidad (Piattini, García, García, Ignacio y Pino, 2012):
1) Operación del producto:
 En este ámbito se consideran conceptos como, por ejemplo, facilidad de uso,

integridad, corrección, fiabilidad y eficiencia.

 Los factores de calidad son los siguientes:
 
 Facilidad de uso: cuán fácil resulta utilizar el software.
 
 Integridad: respecto a si el sistema y sus datos son seguros.
 
 Corrección: 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 desempeña en la plataforma de hardware que tengo.

2) Revisión del producto:
 En este ámbito se consideran conceptos como, por ejemplo, facilidad de

 mantenimiento, facilidad de prueba y flexibilidad.
 
 Facilidad de mantenimiento: cuán fácil resulta corregir errores o mejorarlo.
 
 Facilidad de prueba: cuán fácil resulta testearlo.
 
Flexibilidad: si me permite o no modificarlo.

3) Transición del producto:
 En este ámbito se consideran conceptos como, por ejemplo, facilidad de reutilización,

 interoperabilidad y portabilidad.
 
 Facilidad de reutilización: si es factible reutilizar parte o todo el producto.
 
 Interoperabilidad: cuán complejo resulta comunicarlo con otros sistemas.

Portabilidad:cuán complejo es migrarlo de una máquina a otra (distintas
tecnologías).
10
El concepto de calidad abarca, entonces, tres aspectos en un producto de software: (1) operación
del producto, (2) revisión del producto y (3) transición del producto. Y es a partir de estos
conceptos desde donde se definen las características 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 través de métricas utilizadas para cuantificarlos. A continuación se
muestra un detalle de criterios en cada uno de los factores de calidad indicados.
Figura 1: Criterios para la operación del producto

Fuente: material elaborado para esta asignatura (J. Reyes, 2015)
11
Figura 2: Criterios para la revisión del producto
Figura 3: Criterios para la transición del producto

Sobre la base de lo anterior, el modelo permite cuantificar la calidad del producto, haciendo lo
siguiente:
 Identificación de los factores que determinan la calidad del software

  Establecer criterios de evaluación para cada factor
 Establecer métricas para los criterios y una función de normalización que determine la
relación entre las métricas y los factores.
12
  Evaluación de métricas
 Correlación de las métricas a un conjunto de guías que cualquier equipo de desarrollo
 podría seguir
 Desarrollo de las recomendaciones para la colección de métricas
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 también lo siguiente:
 Las características particulares del propio producto que se está diseñando.


 La relación calidad vs. precio, identificando la relación 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.
Además, sindicar los valores deseables para los criterios, donde es necesario emplear datos
históricos, el promedio en la industria, con los cuales se debe establecer los valores finales y otros
intermedios o predictivos en cada período de medición durante el desarrollo, así también, valores
mínimos aceptables.
Durante el desarrollo hay que establecer métricas, analizar sus resultados y sensibilizar los valores
registrados. Posteriormente, finalizado el proyecto, realizar una comparación de medidas
predictivas utilizadas y ver si se pueden tomar como indicadores de los valores finales.
2.2. MODELO DE CALIDAD DE BOËHM
El modelo de Boëhm se caracteriza por tener una estructura jerárquica y presentar los criterios de
calidad en tres grandes divisiones. El primero de ellos, también denominado de alto nivel, está en
función de los servicios que el sistema ofrece (portabilidad). La segunda división se enfoca en la
operación del producto (usabilidad) y, por último, la tercera división 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 informáticos de manera correcta
3) Su utilización y aprendizaje sean limpios, claros y fáciles
4) Esté bien diseñado, codificado, probado y sea fácil de mantener.
13
Es un modelo que enriquece al de McCall, pero es muy similar, ya que posee una jerarquía de
características y se basa en un amplio rango de características. Incorpora 19 criterios que incluyen
características de performance del hardware.
A continuación, en la Figura 4, se muestra cómo se dispone este modelo.
Características de Utilidad, mantenimiento, portabilidad

alto nivel
Características de
Portabilidad, fiabilidad, eficiencia,
Modelo de Boëhm nivel intermedio usabilidad, capacidad de prueba,
(factores de
comprensibilidad, flexibilidad
calidad)
Características Independencia, completitud, exactitud,

primitivas consistencia, eficiencia, accesibilidad,
comunicatividad, estructuración,
autodescriptividad, concisión,
legibilidad, expansividad
Figura 4: Modelo de Boëhm

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

siguiente:
Características de alto nivel:
 Se refieren específicamente 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 operación 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 Ingeniería social: se refiere al entendimiento y aceptación del sistema por parte
del usuario solicitante de la solución.
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 código
fuente del software, es decir, la lógica asociada es fácil de entender.
o Entendibilidad: es la claridad de la lógica del código fuente de una pieza de
software.
o Modificabilidad: este atributo del software facilita la incorporación de
modificaciones durante la vida útil del producto. Asimismo, está directamente
relacionado con el atributo de entendibilidad, debido a que si el código es
entendible, podrá ser modificado sin que los cambios produzcan efectos
negativos.
Tercer nivel
 Son características de uno o más 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 informáticos de manera correcta y eficiente

 Sea fácil de utilizar y aprender

 Sea bien diseñado, codificado, probado y mantenido
En la siguiente figura aparece una breve comparación entre los modelos de McCall y Boëhm.
15
Figura 5: Comparación entre McCall y Boëhm
Fuente: material elaborado para esta asignatura (J. Reyes, 2015).
3. HERRAMIENTAS BÁSICAS DE CALIDAD

3.1. DIAGRAMA DE FLUJO
Los diagramas de flujo corresponden a un método gráfico 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 comunicación 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 representación de un problema a través de un diagrama de flujo, será necesario
conocer la nomenclatura que define este método. Algunos de los símbolos utilizados son los
presentados en la siguiente tabla. Se sugiere investigar otros símbolos y su utilización.
Símbolo Descripción Símbolo Descripción

Inicio o fin del programa Conector para unir el
flujo a otra parte del
diagrama
Identifica un proceso Líneas de dibujo
Toma de decisión o
ramificación ante un
evento
Figura 6: Elementos gráficos 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 símbolos se unen con líneas, las cuales tienen una flecha indicando el sentido del flujo
(idealmente trazarlas en forma vertical u horizontal).
3) Evitar el cruce de líneas, para no “ensuciar el dibujo”.
4) No deben quedar líneas huérfanas. Esto es, líneas de flujo sin conectar.
5) Todo texto en los símbolos debe representar un verbo (asignar, contar, validar, calcular…).
6) Todo símbolo puede tener más de una línea de entrada, a excepción del símbolo final.
7) Solamente los símbolos de decisión pueden tener más de una línea de salida (usualmente
dos).
A continuación se presenta un ejemplo de un diagrama de flujo.
Figura 7: Ejemplo de un diagrama de flujo

3.2. DIAGRAMA CAUSA-EFECTO
También conocido como diagrama de Ishikawa, porque fue creado por Kaoru Ishikawa, experto en
dirección de empresas e interesado en mejorar el control de calidad. Otros lo llaman diagrama
“espina de pescado” dada que su forma gráfica que se asemeja al esqueleto de un pez, o bien,
diagrama de causa y efecto.
17
Este diagrama se usa para mostrar la relación entre distintos factores que pueden llegar a
determinar un evento determinado. Idealmente se sugiere su utilización para analizar y discutir
entre varios participantes una problemática determinada.
La forma de representación de este diagrama es con un rectángulo (cabeza) ubicado a la derecha

del diagrama, una línea horizontal (columna vertebral) que apunta al rectángulo y sobre esta (la
línea) convergen una serie de líneas (espinas) que van representando información (causas) de
interés para el análisis del problema.
Figura 8: Diagrama Ishikawa (Causa-Efecto)

Por ejemplo, revise la siguiente situación, en que una empresa forestal analiza las principales
causas y efectos en su modelo productivo para poder mitigar los daños ambientales que se
desprenden de su funcionamiento y que, por cierto, provocan un problema legal según las normas
ambientales vigentes.
Figura 9: Ejemplo de aplicación 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. También se podrían considerar causas secundarias, por
ejemplo, las siguientes:
Mantenimiento
Figura 10: Variación y detalle aplicado en el modelo

Al analizar los aspectos asociados al uso de maquinaria, hay varios temas que considerar. Uno de
ellos sería revisar si la política actual para el mantenimiento es la adecuada según las normas
medioambientales vigentes.
De esta forma, si se revisaran cada una de ellas, se lograría establecer un mapa de causas y
efectos, los cuales podrían 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 aplicación
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. Según 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 utilización de este principio es aplicable a lo siguiente:
  Identificar el o los principales factores de un problema.

  Determinar el factor más importante de un problema.
  Identificar el objeto de mejora y qué aspectos de este se pueden mejorar.
 Analizar posteriormente a su aplicación, el efecto de las medidas tomadas para corregirlo.
19
Para aplicar este principio, se deben ejecutar las siguientes actividades:
a) Recolección de datos asociados a una problemática que se está analizando, tratando de

identificar grupos o categorías de datos.
b) Contabilizar por cada categoría el número de ocurrencias que muestra el universo de
datos seleccionado.
c) Asignar porcentajes a cada categoría.
d) Construir una gráfica con la información analizada y los cálculos de porcentajes obtenidos.
Un ejemplo sencillo:
En una planta de producción industrial han ocurrido una serie de interrupciones, las cuales
obedecen a una serie de eventos no deseados. Luego de hacer un registro estadístico de estos, se
obtuvo la siguiente tabla de datos, los cuales se presentan en la Figura 10.
Figura 11: Categorización motivos de pérdidas

Las categorías de eventos se muestran en la columna pérdida. 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 información a un gráfico construido con la herramienta Microsoft Excel, se obtuvo lo

siguiente:
20
Aplicación principio de Pareto
Figura 12: Aplicación del principio de Pareto

Si se considera como punto de quiebre un 80% del acumulado (ver el círculo rojo), se puede
establecer que la principal causa de las pérdidas en la producción es el fallo de UPS, microcortes y
caída de sistemas, que es donde se debiera invertir el esfuerzo para mejorar el proceso
productivo.
3.4. DIAGRAMA DE CONTROL
Es un método de control estadístico 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 disposición que refleja
una línea central con dos límites, uno inferior y otro superior. Así, cuando las entradas que genera
el resultado de la línea productiva escapan a uno de los dos límites establecidos (inferior o
superior), se levantan las alertas para analizar y atender las necesidades del proceso para su
normalización.
El proceso se encuentra bajo control estadístico cuando se producen variaciones por motivos
aleatorios. Mientras que el proceso se encuentra fuera del proceso estadístico cuando las
variaciones son producto de motivos no aleatorios.
De cada proceso que se requiere medir es necesario registrar muestras periódicas de una o más
variables de análisis. 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 período.
Ajustando estas definiciones a la producción de software, las “piezas con fallas” corresponderían,
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 gráfico estadístico 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 programación por programa, si se quisiera mejorar aun más,
se podría establecer que el máximo número de errores fuera cinco, y medirlos posteriormente,
habiendo atendido también las causas que los generaban.
22
COMENTARIO FINAL
La calidad en la producción de software es de vital importancia, dado que ayuda a las empresas a
cumplir con fluidez sus objetivos estratégicos, maximizar el costo de sus inversiones en la
implantación de nuevos sistemas, mejorar el apoyo a las áreas en el desempeño de sus funciones,
brindar mejor atención a sus clientes finales y disponer en forma oportuna de la información
necesaria para la mejor gestión y planificación de los recursos.
El contenido de esta semana entrega una visión 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 específicos.
23
REFERENCIAS
Piattini, M.; García F.; García, I. y Pino, F. (2012). Calidad de sistemas de información. México:
Alfaomega Grupo Editor S. A.
Fernández de Velasco, J. (2013). Gestión por procesos. España: 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
a
Pressman, R. (2010). Ingeniería de software, un enfoque práctico. 7. ed. España: 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 básicas de calidad. Modelos y Control de Calidad. Semana
1.
24
25

Contenido 01 Modelos y Control de Calidad

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Contenido 01 Modelos y Control de Calidad

Încărcat de

Drepturi de autor:

Formate disponibile

MODELOS Y CONTROL DE CALIDAD

CONCEPTOS Y HERRAMIENTAS BÁSICAS DE CALIDAD ........................................................................ 5

Por ejemplo, si se quiere comprar un vehículo y tenemos un presupuesto acotado, se tratara de

1.1. CONCEPTO DE CALIDAD

1.1.1. ¿QUIÉN DEFINE LA CALIDAD?

  “Propiedad o conjunto de propiedades inherentes a algo, que permiten juzgar su valor”.

1.1.2. CONCEPTO DE CONTROL DE CALIDAD

Anteriormente se mencionó la calidad como una característica de un sistema de software, la cual

1.1.3. CONCEPTO DE CALIDAD DEL SOFTWARE

De esta forma, si se acerca la definición de calidad al ámbito de los sistemas de software, se

 Concordancia de los requerimientos funcionales con los productos de desarrollo

  El software es lógico, no físico.

1.2. IMPORTANCIA DE LA CALIDAD

Es bueno reforzar también 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.

Anteriormente se entregaron conceptos que definen la calidad en su amplio contexto de

  Un proceso que gobierna el desarrollo del software (métodos y herramientas).

2. MODELOS CLÁSICOS DE CALIDAD

A continuación, se presentan dos modelos de calidad, elaborados por Boehm y McCall

1) Operación del producto:

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

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

3) Transición del producto:

 En este ámbito se consideran conceptos como, por ejemplo, facilidad de reutilización,

Figura 1: Criterios para la operación del producto

Figura 3: Criterios para la transición del producto

 Identificación de los factores que determinan la calidad del software

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

Asimismo, considerar también lo siguiente:

 Las características particulares del propio producto que se está diseñando.

2.2. MODELO DE CALIDAD DE BOËHM

1) Funcione como el usuario espera que lo haga

A continuación, en la Figura 4, se muestra cómo se dispone este modelo.

Características de Utilidad, mantenimiento, portabilidad

Características Independencia, completitud, exactitud,

Figura 4: Modelo de Boëhm

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

Características de alto nivel:

 Se refieren específicamente a requerimientos generales de uso.

 Representan los factores de calidad del modelo

 Son características de uno o más factores de calidad.

 Haga lo que desea el usuario

3. HERRAMIENTAS BÁSICAS DE CALIDAD

Símbolo Descripción Símbolo Descripción

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

A continuación 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 representación de este diagrama es con un rectángulo (cabeza) ubicado a la derecha

Figura 8: Diagrama Ishikawa (Causa-Efecto)

Figura 9: Ejemplo de aplicación del modelo

Figura 10: Variación y detalle aplicado en el modelo

3.3. DIAGRAMA DE PARETO

Es importante notar que la utilización de este principio es aplicable a lo siguiente:

  Identificar el o los principales factores de un problema.

a) Recolección de datos asociados a una problemática que se está analizando, tratando de

Figura 11: Categorización motivos de pérdidas

Al llevar la información a un gráfico construido con la herramienta Microsoft Excel, se obtuvo lo

Figura 12: Aplicación del principio de Pareto

3.4. DIAGRAMA DE CONTROL

Es un método de control estadístico enfocado en el proceso productivo, el cual ayuda a identificar

Alfaomega Grupo Editor S. A.

Fernández de Velasco, J. (2013). Gestión por procesos. España: ESIC Editorial.

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