UNIVERSIDAD AUTONOMA DE NUEVO LEÓN

FACULTAD DE INGENIERIA MECANICA Y ELECTRICA

Calidad de Software
MC. Guillermo Farías Lara
Actividad 4: Métodos y Herramientas del SUA.

Nombre Matricula Carrera

Brayan Israel Sánchez Ledezma 1676516 IAS

Frecuencia: Martes
Hora: N4-N6
Salón: 4-203
Grupo: 008

Semestre Enero-Junio 2018

 Resumen N°4
Capitulo #8 Calidad de las personas.

Panorámica general.
Hoy en día la calidad del software no puede garantizarse únicamente centrando los
programas de calidad en el producto, dado que, tal y como se ha comentado en el
capítulo 6, la calidad final del producto software está muy directamente relacionada
con la forma en que se desarrolla y mantiene, es decir, con el proceso. Todo ella ha
motivado en gran medida que las organizaciones dedicadas al desarrollo y
mantenimiento del software se preocupen cada vez más de la mejora de sus
procesos.
Modelos de procesos del ciclo de vida, como el ISO/Ec 12207 0 el ISO 15288
para la ingeniería de sistemas, que han sido resumidos en el capítulo anterior.
Estándares y guías, que establecen 10 que debería hacerse en una situacion
contractual, como las normas ISO, estándares como el EIA Ínterin Standard (IS) 632
para procesos de ingeniería de sistemas, 0 los estándares militares como el MIL-
STD-498 (desarrollo y documentaci6n de software).
Modelos de mejora y métodos de valoración interna, que establecen un camino
a seguir describiendo las características de los buenos procesos, como CMM/CMMI
y sus modelos asociados (PSP, TSP, etc), Bootstrap, Trillium para
telecomunicaciones, etc.
Métodos de selección de contratistas, que especifican el examen de los procesos
de una organizaci6n por alguien extremo (segunda o tercera parte) con el fin de
comparar las fortalezas y debilidades de los contratistas para poder minimizar el
riesgo de la compra. Por ejemplo, Software Capability Evaluation (SCE) o el SDCE
de las Fuerzas Armadas de EE. UU.
Premios a la calidad, como el Malcolm Baldrige Nacional Quality A,mrd, European
Quality Award, que han sido tratados en el capítulo 3.

La norma ISO 90003.

La norma ISOIIEC 90003 (ISO, 2004£) proporciona la guía necesaria en las
organizaciones para la aplicación de la ISO 9001 (ISO, 2000b) a la adquisición,
suministro, desarrollo, operaci6n y mantenimiento de software y sus servicios
relacionados. Identifica todos los aspectos que deberían ser tratados y es
independiente de la tecnología, modelos de ciclo de vida, procesos de desarrollo y
estructuras organizacionales.
Según la norma ISO 90003 la organización debe establecer, documentar,
implementar y mantener un sistema de gestión de la calidad software y mejorar
continuamente su eficacia de acuerdo con los siguientes requisitos generales:
Identificar los procesos necesarios para el sistema de gestión de la calidad y su
aplicación a través de la organización. En este punto la organización debería
identificar también los procesos de desarrollo. operación y mantenimiento de
software.
Determinar la secuencia e interacción de estos procesos. La organización
debería también definir la secuencia e interacción de los procesos en: los modelos
de ciclos de vida del desabollo de software, por ejemplo, modelos en cascada,
incremental y en espiral (evolutivos); la planificaci6n de la calidad y el desarrollo,
que debería basarse en un modelo de ciclo de vida.
Determinar los criterios y métodos necesarios para asegurarse de que tanto la
operación como el control de estos procesos sean eficaces.
Asegurarse de la disponibilidad de recursos e información necesarios para
apoyar la operación y el seguimiento de estos procesos.
Realizar el seguimiento. la medición y el análisis de estos procesos.
Implementar las acciones necesarias para alcanzar los resultados planificados y
la mejora continua de estos procesos.

El Modelo de madurez de la capacidad (CMM) y los métodos más

representativos de evaluación y mejora asociados.
CMM.
Desde la década de los años 80, el Instituto de Ingeniería del Software (SEI,
Software Engineering institute) de la Universidad de Carnegie Mellon se ha centrado
en proporcionar la base necesaria para mejorar el desarrollo del software
considerando a las tareas de desarrollo del software como una serie de procesos
que se pueden definir, medir y controlar. Como resultado se han obtenido modelos
de referencia de la capacidad de los procesos y modelos de evaluación de dicha
capacidad.
Evaluar la madurez de los procesos de desarrollo de software dentro de una
organización.
Proponer un plan de mejora de los procesos de desarrollo de software de acuerdo
con una serie de niveles.
Áreas clave del proceso. Cada nivel de madurez. excepto el nivel inicial se
descompone en diferentes áreas clave del proceso. Ejemplos de áreas clave son la
gestión de configuración y planificación del proyecto del segundo nivel de madurez,
o la prevención de defectos y gestión de cambio del proceso. correspondientes al
nivel quinto de madurez. Cada área clave contiene un conjunto de objetivos o metas,
que describen de forma general que se debe hacer para dar soporte a un área clave
de proceso. Las metas se usan para comprobar si efectivamente se implementa
adecuadamente un área clave de proceso determinada.
Características Comunes. Cada área clave de proceso se organiza en una serie
de características comunes que representan los atributos que debe tener el proceso.
Mediante la evaluación de las características comunes se puede averiguar si la
implementación de un área clave de proceso se ha realizado de forma que sea
efectiva, repetible y duradera.
Practicas Clave. Constituyen los ejemplos de que se debe hacer para satisfacer
los objetivos de un área clave de proceso sin entrar en detalle de cómo hacerlo.

SCE (Software Capability Evaluation)

SCE (Byrnes y Philips, 1996) es el método desarrollado para evaluar los procesos
software de una organización con el objetivo de determinar su capacidad. La
capacidad de un proceso se refiere al rango de los resultados esperados que se
pueden obtener al llevar a cabo un proceso determinado.
Las principales áreas de aplicación de SCE son: la selección del suministrador,
la monitorización del proceso y la evaluación interna. SCE usa el modelo de
madurez de capacidad (CMM) como modelo de referencia. El objetivo de la
evaluación de SCE es el proceso software. y en particular. se centra en conjuntos
de procesos (o 10 que en CMM se considera como áreas clave de procesos) que
se pueden agrupar en tres categorías: procesos organizacionales. que contienen
un conjunto de áreas clave que se centran sobre la gestión organizacional de los
procesos software: los procesos de gestión de proyectos. centrados en aspectos
de gestión de proyectos como su planificación y seguimiento: y los procesos de
ingeniería. que incluyen aspectos de desarrollo del producto como la gestión de
requisitos, ingeniería del producto, revisiones por pares, etc.

CBA-IPI (CMM-Based Appraisal for Internal Process Improvement)

CBA-IPI (Dunaway y Masters, 2001) es un método que facilita a una organización
conocer la capacidad de sus procesos software mediante la identificación de las
fortalezas y debilidades y la relación de estas fortalezas y debilidades en base al
modelo CMM, con el fin de establecer y dar prioridad a planes de mejora software y
para facilitar que la organización se centre en la mejora de los aspectos que Ie
resulten más beneficiosos en función de su nivel de madurez y sus objetivos de
negocio.
Los dos principales objetivos de CBA IPI son:
• Dar soporte, habilitar y animar a una organización a la mejora del proceso
software.
• Proporcionar una visión exacta de las fortalezas y debilidades de los
procesos software actuales de la organización, usando CMM como modelo
de referencia y para identificar las áreas clave del proceso que es necesario
mejorar.
Los resultados de la evaluación de los métodos comentados anteriormente se
pueden utilizar en el contexto de la mejora de procesos software. ya sea para la
mejora de los procesos de la propia organización evaluadora (CBA-IPI) o para
mejora en la organización evaluada (SCE).

Ideal.
Iniciación, que constituye el punto de partida, en el cual se establece la
infraestructura, los roles y responsabilidades que hay que asumir y se asignan los
recursos necesarios. En esta fase se elabora el plan de mejora de procesos que
proporciona la guía necesaria para completar el inicio y llevar a cabo las fases de
diagnóstico y establecimiento.
Diagnóstico, en la que se lleva a cabo el trabajo preliminar necesario para realizar
las fases posteriores. En esta fase se inicia el plan de acción de la mejora de
acuerdo con la visión de la organización, el plan de negocio estratégico, las
lecciones aprendidas de esfuerzos de mejora realizados en el pasado, aspectos
clave a los que se enfrenta la organización y los objetivos a largo plazo.
Establecimiento, durante la cual se priorizan los aspectos que la organización ha
decidido mejorar, se desarrollan las estrategias necesarias para obtener las
soluciones de mejora y se completa el borrador del plan de mejora definido en las
fases anteriores. En esta fase también se desarrollan objetivos medibles a partir de
los objetivos generales fijados en la fase de inicio y que son incluidos en el plan de
mejora.
Actuación, en la que se crean y se llevan a cabo las acciones destinadas al mejorar
las áreas identificadas en las fases previas. Se desarrollan planes para ejecutar las
acciones de mejora y para evaluar o probar los procesos nuevos o mejorados. Una
vez completada exitosamente la prueba de nuevos procesos y tras determinar su
adecuación para ser adoptados en la organización. Se desarrollan y ejecutan los
planes necesarios para su implantación.
Aprendizaje, cuyo objetivo es tratar de hacer más efectiva la siguiente iteración por
el modelo IDEAL cuando sea necesaria. Una vez alcanzada esta fase, se han
desarrollado las soluciones, se han aprendido importantes lecciones del proceso y
se han tomado mediciones sobre el rendimiento y la consecución de los objetivos
marcados. Estos artefactos son añadidos a la base de datos del proceso, que
constituye una fuente de información muy relevante para el personal implicado en
la próxima iteración por las fases del modelo.

PSP (Personal Software Process)

EI Proceso de Software Personal (PSP) apoya a las empresas que están llevando
a cabo o tienen planeado implementar un plan de mejora de procesos basados en
un modelo como CMM, ayudando a crear personal capacitado y disciplinado en su
trabajo.
Entre los beneficios que PSP ofrece a los ingenieros software destacan los
siguientes:
• Proporciona una serie de principios al ingeniero para llevar a cabo un proceso
personal disciplinado.
• Asiste a los ingenieros en la realización de planes precisos.
• Determina los pasos que los ingenieros deben seguir para mejorar la calidad
del producto.
• Establece bancos de pruebas para medir la mejora del proceso personal.
• Determina el impacto que los cambios del proceso tienen sobre el
rendimiento del ingeniero.

La Línea Base del Proceso Personal (PSPO y PSPO.1), que proporciona una
introducción al PSP y establece la base inicial a partir del histórico de datos de
tamaño, tiempos y defectos.
Gestión Personal del Proyecto (PSP 1 Y PSP 1.1). se centra en las técnicas para
la gestión del proyecto a nivel individual. Se introducen métodos para la estimación
del esfuerzo y planificación y seguimiento de calendario. Las estimaciones de
tamaño y esfuerzo se realizan usando el método PROBE (Proxy-Based Estimating).
con el que los ingenieros usan el tamaño relativo del Proxy. como por ejemplo
objetos. puntos función. procedimientos. y los transforman a líneas de código (LOC).
Gestión Personal de la Calidad (PSP2 y PSP2.1), añade métodos de gestión de
la calidad a PSP tales como: revisiones personales de diseño y código, una notación
para el diseño, plantillas de diseño, técnicas de verificación y métricas para
gestionar la calidad del proceso y del producto. EI objetivo es encontrar y eliminar
todos los defectos antes de llegar a la primera compilación, para 10 cual se define
una métrica de rendimiento definida como el porcentaje de defectos introducidos
que fueron eliminados antes de la compilación.
Proceso Personal Cíclico (PSP3), que resuelve la necesidad de escalar PSP de
manera eficiente a proyectos de mayor tamaño sin sacrificar la calidad o la
productividad. En este nivel los ingenieros deben aprender a alcanzar la
productividad más alta en un determinado rango de tamaño. Por debajo de este
rango la productividad tiende a disminuir debido a costes generales. Por encima de
este rango la productividad también tiende a disminuir porque se ha alcanzado el
límite de escalabilidad del proceso.

TSP (Team Software Process)

EI Proceso de Software de Equipo (TSP) (Humphrey, 2000a; 2000b) ayuda a
conformar equipos para el desarrollo de software de calidad. TSP proporciona ill1
marco de trabajo, que se construye sobre la base de PSP, con fases de desarrollo
bien definidas, en las que los productos de software se generan en varios ciclos.
EI origen de TSP se debe a las limitaciones que PSP tenía en el ámbito industrial
(McAndrews, 2001). PSP ha tenido un gran éxito en entornos académicos y de
hecho los datos obtenidos de los alumnos que han aplicado PSP han sido muy
consistentes. Este hecho creo una evidencia muy significativa sobre los beneficios
que los ingenieros obtendrían al usar PSP: les permitiría tener el control de su
proceso personal mediante la mejora de sus habilidades de estimación y la
reducción de los defectos introducidos en los productos sin afectar a su
productividad. Sin embargo, no quedaba claro como los ingenieros podrían aplicar
estas habilidades en la práctica dentro de las empresas.
TSP proporciona un proceso operacional definido para guiar a los ingenieros y
gestores sobre los pasos necesarios en la construcción de equipos. Los procesos
operacionales son procesos que definen de forma precisa el trabajo a realizar y se
consideran como guiones más que como las descripciones textuales muy extensas
que aparecen en los libros de definición de los procesos de la organización. Estos
guiones son diseñados para facilitar su uso por los miembros de equipo cuando
están realizando su trabajo. El proceso especifica los pasos necesarios para
establecer un entorno efectivo de trabajo en equipo.
De acuerdo con TSP, los equipos son relanzados periódicamente. Ello se debe a
que TSP sigue una estrategia de desarrollo iterativa y evolutiva, lo que hace que los
relanzamientos periódicos sean necesarios de forma que cada fase o ciclo pueda
ser planificado de acuerdo con el conocimiento obtenido en los ciclos previos. El
relanzamiento también es necesario para actualizar los planes detallados de los
ingenieros, que normalmente son precisos solo para unos pocos meses. En cada
relanzamiento los equipos hacen un plan global y un plan detallado de los tres
meses o cuatro meses posteriores.
Durante cada lanzamiento del equipo también se elabora el plan de calidad. Para
gestionar la calidad los equipos establecen métricas y objetivos de calidad, así como
planes para alcanzar dichos objetivos y los medios para conocer el progreso y llevar
a cabo acciones colectivas cuando no se satisfacen los objetivos. TSP enseña a los
equipos como deben realizar este proceso de gestión de calidad mediante guiones
en los que se definen las métricas a usar como parte del proceso.

People Capability Maturity Model (People-CMM)

El modelo People CMM está diseñado sobre la premisa de que las prácticas de
mejoras de los empleados no tendrán éxito al menos que el comportamiento de la
organización cambie para darles soporte. Es un modelo basado en el proceso que
asume que las prácticas de los empleados son procesos estándares de la
organización que pueden ser mejorados de forma continua mediante los mismos
métodos que se utilizan para otros procesos de negocio. People OHM consiste en
cinco niveles de madurez a través de los cuales las prácticas y procesos de las
fuerzas de trabajo van evolucionando. Estos niveles establecen las bases
necesarias para la mejora continua de las competencias individuales, el desarrollo
de equipos efectivos, la motivación en la mejora del rendimiento y el establecimiento
de las fuerzas de trabajo que la organización necesita para llevar a cabo sus planes
de negocio.
En el nivel inicial, las organizaciones tienen dificultades para retener a los individuos
con talento y a pesar de su importancia. las prácticas de los empleados son ad hoc
e inconsistentes. En algunas áreas no existen definidas prácticas para los
empleados y en las que existen, el personal no está formado para llevarlas a cabo.
El primer paso hacia la mejora de la capacidad de los empleados consiste en
obtener directores que asuman las actividades de los empleados como
responsabilidades de alta prioridad. Las practicas implementadas en el nivel
gestionado se centran en la atención del director sobre aspectos a nivel unitario
como dotación de personal compromisos de coordinación, proporcionar recursos,
gestionar el rendimiento, tomar decisiones de compensación, etc., Por 10 tanto, el
nivel 2 de madurez se centra en establecer practicas base dentro de las unidades
que resuelva los problemas más inmediatos y prepare a los directores para
implementar practicas más sofisticadas en niveles superiores.
En el nivel definido, la organización construye un marco de trabajo de
competencias de los empleados a través de toda la organización. Cada
competencia de empleado es un elemento de la arquitectura y se describen las
interacciones entre estos elementos mediante dependencias entre los procesos
basados en competencias, Esta arquitectura es de carácter estratégico y por lo tanto
debe evolucionar de acuerdo con la evolución de las condiciones de negocio y de
la tecnología.
En el nivel predecible. la organización gestiona y explota la capacidad creada en
el nivel anterior. En este punto, la organización es capaz de gestionar su capacidad
y rendimiento de forma cuantitativa y ella permite predecir su capacidad para
realizar su trabajo. Dentro de cada unidad o grupo de trabajo, se mide el rendimiento
a la hora de realizar los procesos basados en competencias que son críticos para
los objetivos de negocio.
En el nivel optimizaste, la organización al completo se centra en la mejora continua.
La organización usa los resultados del nivel anterior para guiar las mejoras de este
nivel Estas mejoras están orientadas a la capacidad de los individuos y grupos de
trabajo, al rendimiento de los procesos basados en competencias y a las prácticas
y actividades de los empleados.

El Estándar ISO/IEC 15504.

Modelo de Referencia de Procesos, que describe un conjunto de uno o más
procesos en términos de su propósito y de los resultados esperados. El propósito
describe los objetivos a alto nivel que se deben realizar mientras y los resultados
esperados describen los resultados que se deben obtener tras una exitosa ejecución
de dichos procesos. Los estándares ISO/IEC 12207:1995 y ISO/lEC 15288
proporcionan modelos de referencia de procesos.
Marco de Trabajo de Medición para la Capacidad del Proceso, que define una
escala ordinal de seis valores para representar la capacidad del proceso que varía
desde los procesos que no son capaces de realizar su propósito (nivel 0) a los
procesos que optimizan su rendimiento de forma continua (nivel 5).
Modelo de Evaluación del Proceso, que proporciona el mecanismo mediante el
cual se relacionan los modelos de evaluación del proceso y el marco de trabajo de
la medición. Los modelos de evaluación se basan en las descripciones de proceso
incluidas en los modelos de referencia del proceso. Con el fin de asegurar que los
resultados de la evaluación son traducibles a un perfil de proceso de ISO 15504 de-
una forma fiable y repetible, los modelos de evaluación deben adherirse a ciertos
requisitos, de forma que un modelo de evaluación de procesos es conforme si: es
adecuado de acuerdo al propósito de la evaluación; sus elementos relevantes se
corresponden con los procesos descritos en el modelo de procesos de referencia y
con los atributos de proceso descritos en la segunda parte de ISO 15504.
Herramientas de Evaluación, que deben dar soporte a la reunión, registro.
almacenamiento, análisis, recuperación y presentación de los datos de la
evaluación. Para ella puede ser necesario el uso de varias herramientas que pueden
ser "paper-based', como formularios, cuestionarios o listas de comprobación, y
herramientas software para casos en los que el volumen y complejidad de los datos
es mayor.
EI proceso de evaluación está compuesto por las siguientes actividades:
Planificación. en el que se debe desarrollar un plan de la evaluación en el que al
menos se deben incluir: las entradas requeridas que están especificadas en el
estándar, las actividades a realizar para llevar a cabo la evaluación. los recursos y
el calendario asignado a las distintas actividades, la identidad y responsabi1idades
de los participantes en la evaluación. Los criterios para verificar que se cump1en los
requisitos del estándar y una descripción de las salidas planificadas de la
evaluación.
Recopilación de datos, en la que se deben obtener los datos requeridos para
evaluar los procesos dentro del alcance de la evaluación e información adicional.
Esta recopilación debe realizarse de una forma sistemática y debe contemplar la
estrategia y las técnicas necesarias para la selección, obtención. análisis de los
datos y una justificación de las valoraciones realizadas.
Validación de los datos, para confirmar de forma objetiva la evidencia de los datos
obtenidos: asegurar que la evidencia es suficiente y representativa para cubrir el
alcance y propósito de la evaluación; asegurar que los datos son consistentes en
su conjunto.
Valoración de los Atributos del Proceso, de forma que se les asigna una
puntuación en base a los datos validados. El conjunto de puntuaciones de los
atributos del proceso debe ser registrado en el perfil del proceso para la unidad
organizacional definida.
Generación de Informes. en los que se presentan los resultados de la Evaluación,
así como el mínimo de salidas de la evaluación exigidas de acuerdo al estándar.

Mejora de procesos para fomentar la competitividad de la pequeña

y mediana industria del software de Iberoamérica (COMPETISOFT).
Como sabemos, la industria de software representa una actividad económica de
suma importancia para todos los países del mundo, y especialmente para los
iberoamericanos, ya que ofrece múltiples fuentes de ingresos y empleo y se perfila
como una de las oportunidades más importantes en los países en vía de desarrollo.
Este proyecto pretende aglutinar las diferentes alternativas existentes (como las
resumidas en los epígrafes anteriores), aprovechando la sinergia y los
conocimientos de los diferentes países para conseguir un marco metodológico de
ámbito verdaderamente iberoamericano. El hecho de que los países
iberoamericanos compartan un Modelo de Procesos, un Modelo de Capacidades y
un Método de Evaluación aportara grandes ventajas ya que facilitan la colaboración
entre empresas de diferentes países, la movilidad de los profesionales informáticos,
el reconocimiento de certificaciones, la compartición de herramientas de desarrollo,
y el abaratamiento de los recursos formativos. Esto facilitara un aumento en la
calidad y en la cantidad de software desarrollado en Iberoamérica, aumentando las
exportaciones y también el número de factorías de software instaladas en la región,
así como incrementando el número de empleados en el sector.
 Anexo Herramientas de la Calidad.

Diagramas de flujo.
Los diagramas de flujos tienen como objetivo descomponer los pasos de un proceso
en una secuencia. Se pueden emplear los siguientes elementos: secuencias de
acciones, servicios o materiales que entran o salen del proceso, personas
implicadas, tiempo empleado en cada uno de los pasos y medidas del proceso.

Diagrama Causa-Efecto.
También llamado diagrama de espina de pescado (por su forma) o diagrama de
Ishikawa (por su creador), el diagrama causa-efecto es una herramienta que se
utiliza para identificar, explorar, y mostrar todas las posibles causas de un problema
específico (efecto).
Es una herramienta que, combinada con otras de identificación de problemas como
la tormenta de ideas, facilita y potencia el trabajo en grupo.

Diagrama de Pareto
Es una herramienta utilizada para establecer una jerarquía de los problemas o las
causas que los generan, a partir de una representación gráfica de los datos
obtenidos, dando una idea clara y cuantificada del orden en que deben ser
abordados estos problemas o causas. Establece que "al eliminar el 20% de las
causas que generan un problema en una situación resolvería un 80% de ellas,
mientras que el 80% de las causas restantes resuelven el 20% de los problemas
resultantes". EI nombre de Pareto fue dado a esta herramienta por Juran en honor
del economista italiano Wilfredo Pareto que definió la regla 80/20 para explicar la
distribución de las riquezas.

Hoja de chequeo o de comprobación.

La Hoja de Recopilación de Datos también llamada Hoja de Registro. Lista de
Verificación. Chequeo o Cotejo sirve para identificar y analizar tanto los problemas
como sus causas. Para ello establece los mecanismos necesarios para reunir y
clasificar los datos recabados seguir determinadas categorías, mediante la
anotación y registro de sus frecuencias para cada uno de los contextos posibles:
verificación (inspección, chequeo o tare as de mantenimiento), localización de
defectos en las piezas, distribución de variaciones de variables de los artículos,
clasificación de artículos defectuosos, etc.

Grafo o Diagrama de control.

Son representaciones graficas utilizadas para detem1inar desde un punto de vista
estadístico si un proceso está o no bajo control esto es, si hay variabilidad en el
proceso y descubrir a que obedece esta variabilidad. La variabilidad es cualquier
desviación que el producto o servicio final puede tener respecto a la especificación
de los usuarios y que puede ser debida a cualquiera de los elementos.

Diagrama de afinidad.
Los diagramas de afinidad sirven para organizar un gran número de ideas en
categorías relacionadas, o afines (Tague 2005). Fue creado por Kawakita en los
años sesenta.
Las ideas suelen venir de sesiones de trabajo 0 de sesiones de Tormentas de Ideas.

Diagrama de relaciones.
Es una herramienta utilizada para identificar las causas más significativas de un
problema y representar gráficamente los vínculos que puedan existir entre los
factores relacionados con ese problema. Esta herramienta ayuda a un grupo de
trabajo a identificar los enlaces naturales entre diferentes aspectos de una situación
compleja. Los diferentes elementos del diagrama se relacionan entre si con flechas.

Diagrama de matriz o matricial.

Al igual que otras herramientas de las citadas hasta ahora, permite representar
gráficamente la relación existente entre varios factores. Para ella hay que colocar
los factores sobre las filas y columnas de una matriz. Si existe relación, se marca
en la intersección de los factores. Es posible indicar el grado o intensidad de la
relación existente. Se suele utilizar para definir la relación entre los distintos factores
que intervienen directa o indirectamente en un proceso de mejora de calidad.
Matriz de análisis de datos.
Algunos autores como Tague (2005) identifican esta herramienta como un subtipo
de la anterior, Hamada L-Shape, que relaciona dos grupos de elementos entre sí, o
incluso relaciona los elementos dentro del mismo grupo.

Diagrama de redes de actividad o de flechas.

Son una herramienta de planificación que se emplea para representar gráficamente
y de forma estructurada la secuenciación de actividades que hay que desarrollar en
un plan de mejora de calidad siguiendo un orden cronológico. La información que
se debe mostrar es la duración de cada tarea, holgura, dependencias entre
actividades. Tienen un principio y un final, con lo que es posible estimar cuanto
tiempo se va a necesitar para desarrollar el mencionado plan.

Diagrama de árbol.
Se utiliza para representar jerárquicamente los diferentes niveles de complejidad de
un determinado proceso o producto, partiendo de un primer nivel genérico que se
va descomponiendo en niveles de mayor detalle hasta alcanzar un nivel básico o
auto descriptivo.

Diagrama de proceso de decisiones.

Define un plan de actuación de cara a resolver un problema determinado. Se suele
utilizar para implantar planes de actuación de cierta complejidad