Semana 7 – Herramientas Básicas de la calidad

Lo que llamamos las 7 Herramientas de la Calidad es un conjunto de metodologías que fueron

reunidas por Kaoru Ishikawa y están ampliamente difundidas como forma de mejorar los
procesos de las empresas. Desde entonces, se utilizan en los sistemas de gestión para ayudar
en la mejora de los servicios y procesos.

Estas herramientas se utilizan para definir, medir, analizar y proponer soluciones a los
problemas que interfieren en el rendimiento y el resultado de las empresas. Ellas ayudan a
establecer métodos más elaborados de resolución basados en hechos y datos, lo que aumenta
la tasa de éxito de los planes de acción.

Flujograma (Diagrama de Flujo)

Ayuda en la identificación del mejor camino que el producto o servicio recorrerá en el proceso,
es decir, muestra las etapas secuenciales del proceso, utilizando símbolos que representan los
diferentes tipos de operaciones.

los diagramas de flujo son una representación gráfica de las etapas, ramificaciones y decisiones
presentes en nuestros procesos. El diagrama de flujo permite visualizar un proceso mediante
diferentes tipos de “cajas” conectadas con flechas, y ayuda a documentar, comunicar, analizar
y gestionar el proceso.

Diagrama Ishikawa (Espina de Pescado)

Tiene como objetivo identificar las posibles causas de un problema y sus efectos, relacionando
el efecto a todas las posibilidades (causas) que pueden contribuir al problema ha ocurrido.

Resulta de mucha utilidad en este sentido realizar el análisis en equipo, buscando que distintos
puntos de vista estén involucrados (operaciones, mantenimiento, proyectos, calidad, u otros) y
no censurar inicialmente ninguna idea (cual dinámica de brainstorming).
Los pasos son simples: se define el problema central que se quiere resolver y se identifican los
factores o dimensiones principales que se supone son causa del problema. A su vez, dentro de
cada dimensión, se incluyen las causas primarias, secundarias, terciarias, etc, a fin de tener una
representación gráfica del problema.

Hojas de verificación
Es una lista de elementos preestablecidos que se marcarán a partir del momento en que se
realicen o se evalúen. Se utiliza para la certificación de que los pasos o elementos
preestablecidos se han cumplido o para evaluar en qué nivel están. Es similar a un checklist.
Diagrama de Pareto
Es un recurso gráfico utilizado para establecer un arreglo (de mayor a menor, por ejemplo) en
las causas de un determinado problema o no conformidad.

Es una gráfica de barras combinada con gráfica de línea en donde los datos de frecuencia,
tiempo, defectos, costo, etc. se ordenan de manera descendente, de mayor a menor. Esto
permite al analista enfocar sus esfuerzos sobre las categorías de mayor contribución a la
situación planteada.

El proceso es simple, listemos las diferentes causas con su impacto (ventas, cantidad de
defectos, costo de los defectos) y ordenémoslos de mayor a menor. Adicionalmente podemos
incluir el % relativo acumulado.
Histograma
Tiene como objetivo mostrar la distribución de frecuencias de datos obtenidos por mediciones
periódicas, creando así un panorama de los patrones que más se repitieron en un determinado
período de tiempo.

Al analizar temáticas de calidad, pueden existir relaciones en los datos no evidentes a simple
vista. Una herramienta para detectar patrones o comportamientos es la de evaluar cierto
aspecto de acuerdo a cierto agrupamiento de los datos.

El histograma es una representación aproximada de la distribución (forma y dispersión) de

cierto fenómeno en los grupos que estamos analizando.

A su vez, el histograma nos servirá como herramienta de comparación de la distribución de dos

conjuntos de datos. Por ejemplo: defectos por tipo de producto, edades de los clientes de
distintos tipos de producto, comparación entre dos momentos de tiempo distintos u otras.
Los grupos se definen con rangos generalmente de igual tamaño, consecutivos, en los que se
registra el número de observaciones correspondiente.

El histograma nos permite obtener una primera aproximación de la distribución real de los
datos y detectar patrones que sirvan como punto de partida para mejorar y controlar los
procesos.

Diagrama de Dispersión
Muestra lo que sucede con una variable cuando la otra cambia. Son representaciones de dos o
más variables que se organizan en un gráfico, siempre teniendo una en función de la otra.

Estos tipos de diagramas, generalmente de 2 variables en coordenadas cartesianas, nos sirven

también para detectar patrones que inicialmente hayamos podido pasar por alto.

Aparte del análisis visual, existen numerosos análisis que podremos realizar sobre el conjunto
de datos, como por ejemplo entender si existe o no una relación entre las variables analizadas.
Estas correlaciones podrán ser positivas (si una magnitud aumenta la otra también), negativas
(si una aumenta la otra disminuye) o nulas (no existe correlación).

La cantidad y calidad de los datos de los que dispongamos serán variables clave que definirán
qué tan fino podremos hilar sobre la cuestión.

Control Estadístico de Proceso (CEP)

Utilizado para mostrar las tendencias de los puntos de observación en un período de tiempo.
Es un tipo de gráfico utilizado para el seguimiento del proceso, determinando el rango de
tolerancia limitado por la línea superior (límite superior de control) y una línea inferior (límite
inferior de control) y una línea media del proceso (límite central), que fueron estadísticamente
determinadas.

Todo proceso de manufactura o servicios tendrá en mayor o menor medida cierta variabilidad
en sus resultados. Al monitorear y controlar un proceso, queremos saber si la variabilidad del
proceso está dentro de límites razonables (proceso controlado) o si por el contrario
existen causas especiales que puedan estar haciendo que el proceso no funcione
correctamente, a fin de detectarlas y corregirlas.
Los gráficos de control son una herramienta de Control Estadístico de Procesos que nos
permiten realizar este análisis. En función del proceso que estemos analizando se determinan
gráficos de tendencia central y/o dispersión, en los que se podremos fijar valores límites
mínimos y máximos (límites de control inferior y superior), en los que iremos monitoreando
la/s variable/s de interés del proceso.

Métricas de la Calidad de Software

La generación de conocimiento necesita un poso de calidad que se extiende desde el dato
mismo hasta el programa desarrollado para interactuar con la información. Las métricas de
calidad de software permiten monitorizar un producto para determinar su nivel de calidad,
aunque, el seguimiento que este tipo de medidas permiten llevar a cabo brinda la oportunidad
de conocer muchas más cosas de una solución.

Las organizaciones de TI se basan en una variedad de estos KPI para comprender

completamente el progreso de los ingenieros de software, al igual que la calidad del software,
como el rendimiento y la satisfacción del usuario. La gama de posibles medidas abarca cuatro
categorías clave:

1. Productividad del desarrollador

2. Rendimiento del software
3. Defectos y seguridad
4. Experiencia de usuario (UX)

Si bien una organización de TI no necesita tabular todas las métricas de software, debe
priorizar y rastrear las que más importan para sus requisitos y objetivos. Escanee estas 23
métricas de desarrollo de software y cree un conjunto de KPI para la calidad del software.

Métricas de productividad del desarrollador

Existen muchas formas de discutir o evaluar la eficiencia del equipo y el trabajo
completado. Las métricas de productividad permiten a los gerentes de desarrollo ejecutar
mejor los proyectos. Tabule una combinación de estas métricas de software para medir qué
tan avanzado está un proyecto, los niveles de productividad del desarrollador, la cantidad de
tiempo de desarrollo adicional necesario y más.

1. Tiempo de entrega (lead time). El tiempo de entrega es el tiempo que tarda algo de
principio a fin. En el desarrollo de software, por ejemplo, el tiempo de entrega de un
proyecto comienza con la propuesta y termina con la entrega.

2. Cantidad de código. Los equipos de desarrollo pueden mirar esta métrica de software,

también llamada miles de líneas de código (KLOC), para determinar el tamaño de una
 aplicación. Si este KPI es alto, podría indicar que los desarrolladores fueron
productivos en sus esfuerzos de programación. Sin embargo, esta métrica no es útil
cuando un equipo de desarrollo intenta comparar dos proyectos escritos en diferentes
lenguajes de programación. Además, tenga en cuenta que más código no siempre hace
que el código sea eficiente o efectivo, lo que puede significar más trabajo de
refactorización más adelante.

3. Trabajo en curso (WIP). En un contexto de ingeniería de software, WIP es un trabajo

de desarrollo en el que el equipo ha comenzado a trabajar y que ya no está en
el backlog.

4. Velocidad ágil. Para calcular la velocidad, un equipo de desarrollo de software

ágil analiza los sprints anteriores y cuenta el número de historias de usuario o puntos
de historia completados a lo largo del tiempo. La velocidad ágil es una estimación de
qué tan productivo será el equipo en un solo sprint.

5. Tasa de éxito de la meta del sprint. Esta métrica de software calcula el porcentaje de

elementos que completó el equipo de desarrollo en el backlog del sprint. Es posible
que un equipo no termine el 100 % del trabajo durante un sprint determinado. Sin
embargo, el progreso del equipo aún podría cumplir con su definición de terminado: el
umbral que debe alcanzar un proyecto para que una organización lo considere
terminado. Si la iteración cumple con la definición de hecho, es un éxito.

6. Número de versiones de software. Los equipos ágiles y de DevOps dan prioridad a los

lanzamientos de software continuos y frecuentes. Con este KPI, los equipos pueden
realizar un seguimiento de la frecuencia con la que lanzan software, ya sea mensual,
semanal, diaria, por hora o en cualquier otro período de tiempo, y si esa cadencia
finalmente ofrece suficiente valor comercial.

Métricas de rendimiento del software

El rendimiento del software se refiere a medidas cuantitativas del comportamiento de un

sistema de software. Las métricas de rendimiento miden los atributos no funcionales, es
decir, cómo se desempeña una aplicación, no lo que realiza.

7. Aspectos del desempeño del software. Las pruebas de rendimiento pueden evaluar

las siguientes características de una aplicación:

 Escalabilidad

 estabilidad

 capacidad de respuesta

 velocidad

 disponibilidad

Otras expresiones importantes de métricas de rendimiento del software incluyen las

siguientes.

8. Rendimiento (throughput). El rendimiento es la cantidad de unidades de datos que

procesa un sistema en un cierto período de tiempo.
 9. Tiempo de respuesta. El tiempo de respuesta mide cuánto tiempo tarda un sistema en
responder a una consulta o demanda.

10. Fiabilidad, disponibilidad y capacidad de servicio (RAS). RAS se refiere a la capacidad

del software para cumplir constantemente con sus especificaciones; cuánto tiempo
funciona en relación con la cantidad esperada; y con qué facilidad se puede reparar o
mantener.

Métricas de defectos

Los equipos de desarrollo deben comprender cómo fallan las aplicaciones para poder
construirlas mejor. Estas métricas de desarrollo de software evalúan defectos y
vulnerabilidades.

11. Densidad de defectos. A nivel de código, los desarrolladores pueden tabular el

número de defectos por KLOC para evaluar la frecuencia de los defectos.

12. Cobertura de código. Esta es la proporción de código fuente que cubren las pruebas
automatizadas. La métrica del software permite a los probadores identificar qué áreas
del código aún tienen que probar correctamente.

13. Porcentaje de detección de defectos. Esta métrica es una proporción de la cantidad de

defectos encontrados antes de los lanzamientos de software en comparación con el
número encontrado después del lanzamiento. Para calcular el porcentaje, tome el
número de defectos encontrados antes del lanzamiento (x) y la cantidad que
encontraron los usuarios después del lanzamiento (y), y luego calcule x/(x + y). Es
preferible un alto porcentaje, ya que eso significa que se encontró una mayor
proporción de defectos antes de que los clientes usaran el software.

14. Deuda técnica. La deuda técnica es una metáfora que refleja el esfuerzo a largo plazo,
así como los costos temporales y financieros, de los desarrolladores que no abordan
un problema de desarrollo cuando surge por primera vez.

15. Moral como métrica

Trate la felicidad de los empleados o del equipo como otro indicador útil de la productividad y
el éxito del equipo. Puede que sea tan importante como cualquier métrica técnica o KPI de
calidad del software.

Los miembros del equipo estresados o insatisfechos pueden erosionar la productividad del
trabajo y, en última instancia, el rendimiento del software. Mantenga un inventario de
números como la rotación de los miembros del equipo, también llamada rotación de
empleados; un número más bajo probablemente significa que los empleados están satisfechos
dentro de la organización.

16. Vulnerabilidades de seguridad. Los análisis de vulnerabilidades identifican las

debilidades de seguridad en una aplicación. Cuanto menor sea el número de
vulnerabilidades encontradas, más seguro será el software.

17. Incidentes de seguridad reales. Este KPI cuenta la cantidad de veces que un hacker
aprovecha una vulnerabilidad en el software. Realice un seguimiento de la frecuencia
con la que ocurren estas infracciones, la gravedad del ataque (por ejemplo, qué datos
se robaron) y la cantidad de tiempo que duró el incidente.
Las organizaciones de TI utilizan varios promedios para calcular la ocurrencia de fallas o
defectos de software.

18. Tiempo medio de detección. El tiempo medio de detección es un promedio que indica
cuánto tiempo tarda un equipo en notar un problema o error.

19. Tiempo medio entre fallos. Esta métrica es un cálculo de qué tan común es que un
programa falle.

20. Tiempo medio de reparación. El tiempo medio de reparación es el promedio que

representa la rapidez con que un equipo aborda las fallas.

Métricas de usabilidad y UX

Los usuarios experimentan e interactúan con el software de diferentes formas. Así como es
difícil clasificar las emociones de las personas, también es un desafío evaluar su reacción al
software. Si bien ninguna métrica de software puede comunicar la totalidad de la experiencia
de usuario, hay algunas que son útiles.

21. Métricas de UX. Las mediciones de UX suelen ser cualitativas y pueden incluir las
respuestas emocionales o corporales de los usuarios, como cuánto confían en el
software y cómo se mueven sus ojos a través de una interfaz de usuario.

22. Métricas de usabilidad. La usabilidad mide qué tan bien el software permite a los
clientes alcanzar sus objetivos. La usabilidad se puede dividir en componentes más
pequeños, como los siguientes:

 Facilidad de descubrimiento

 eficiencia

 memorabilidad

 facilidad de aprendizaje

 satisfacción

 accesibilidad, particularmente accesibilidad digital

23. Net Promoter Score (NPS). Esta métrica de software refleja la voluntad de los clientes
de recomendar una aplicación a otros. Net Promoter Score se presenta como un rango
de números de 0 a 10. Los clientes con una puntuación de 0 a 6 son Detractores; las
puntuaciones 7 y 8 son Pasivos; y 9 y 10 son Promotores.

Bibliografía
https://www.atlasconsultora.com/que-son-las-7-herramientas-basicas-de-la-calidad/

https://blogdelacalidad.com/las-siete-herramientas-de-la-calidad/

https://clockwork.com.co/las-7-herramientas-de-la-calidad/

https://www.computerweekly.com/es/consejo/23-metricas-de-desarrollo-de-software-que-
monitorear-hoy