Calidad de Software – Cápsula 16

PARTE 1. CONTROL ESTADÍSTICO DE PROCESOS Y SUS HERRAMIENTAS Esta sección ha sido extractada del libro: “Interpreting the CMMI: a process improvement approach” de Margaret Kulpa y Kent Johnson. ¿Qué es el Control Estadístico de Procesos (CEP)? Se refiere a un conjunto de técnicas utilizadas para ayudar a las personas a entender, analizar e interpretar información numérica. Se usa para identificar y rastrear la variación en los procesos. Variación del rendimiento de un proceso. El rendimiento de un proceso es el conjunto de los resultados obtenidos de las distintas ejecuciones del mismo. La variación es inherente a cualquier actividad Ejemplos: El recorrido de casa al trabajo es el mismo; sin embargo, el tiempo que tardamos cada día en hacerlo varía. Depende de la hora a la que salimos de casa, el número de semáforos rojos en que nos paramos, el tráfico en la carretera a esta hora, etc. El informe que preparamos mensualmente es el mismo, pero el tiempo que tardamos en hacerlo cada mes varía. Depende del número y la complejidad de los asuntos que tratamos en el informe, los destinatarios del informe, el número de interrupciones que nos hacen dejar y retomar la tarea, etc. La variación del rendimiento de un proceso se puede presentar a través de diferentes técnicas descriptivas: gráfico de control (incluyendo la media y los límites naturales de control), histograma, gráfico de cotización, etc. En el modelo CMMI la caracterización del rendimiento de un proceso se llama Línea base de rendimiento (Process Performance Baseline).

1

Calidad de Software – Cápsula 16

Ejemplo: El rendimiento del proceso de Testing se puede presentar a través del número de defectos encontrados por el equipo de Testing, el número de incidencias identificadas por los clientes, el coste de corrección de un defecto. Un gráfico como el siguiente caracteriza la variación del rendimiento del proceso:

Figura 1.1. Ejemplo de gráfico de variación de rendimiento 2

Calidad de Software – Cápsula 16

Usamos los límites naturales de control de la variación del rendimiento de un proceso para conocer hasta qué nivel el proceso cumple con las expectativas establecidas por la empresa y los clientes Y hablamos de Gestión cuantitativa cuando se utilizan los datos de forma proactiva, para predecir el rendimiento en el futuro y para pronosticar el efecto de posibles cambios en un proceso. Lógicamente, para conocer estadísticamente la variación del rendimiento de un proceso y para crear modelos predictivos es necesario tener y analizar suficientes datos históricos de distintos proyectos. En pocas palabras: La gestión cuantitativa ayuda a conocer los factores vitales que determinan el rendimiento de un proceso. Manejando estos factores dinámicamente en el curso de un proyecto o servicio se puede optimizar los resultados del proceso para que cumplan con los objetivos de la empresa y las expectativas de los clientes.

3

Calidad de Software – Cápsula 16

GESTIÓN CUANTITATIVA EN CMMi Área de proceso: Quantitative Project Management (QPM). Representación escalonada: corresponde al nivel 4. Representación continua: categoría de proceso de Gestión de proyectos. Propósito: gestionar cuantitativamente el proyecto para alcanzar los objetivos establecidos de calidad y de rendimiento del proceso del proyecto. Preparación para la gestión cuantitativa del proyecto SG1: La preparación para la gestión cuantitativa es realizada. SP1.1.

Establecer y mantener los objetivos de calidad y de rendimiento del proceso del proyecto.

SP1.2.

Utilizar la estadística y otras técnicas cuantitativas para componer el proceso definido que permite al proyecto alcanzar los objetivos de calidad y de rendimiento del proceso.

SP1.3.

Seleccionar los subprocesos y atributos críticos para evaluar el rendimiento y que ayudan a alcanzar los objetivos de calidad y rendimiento del proceso del proyecto.

SP1.4.

Seleccionar las medidas y las técnicas analíticas a usarse en la gestión cuantitativa.

Gestión cuantitativa del proyecto SG2: El proyecto es gestionado cuantitativamente. SP2.1.

Monitorizar el rendimiento de los subprocesos seleccionados utilizando la estadística y otras técnicas cuantitativas.

SP2.2.

Gestionar el proyecto utilizando la estadística y otras técnicas cuantitativas para determinar si o no los objetivos de calidad y rendimiento rendimiento del proceso del proyecto serán satisfechos.

SP2.3.

Realizar análisis de causa raíz de los problemas seleccionados para atender las deficiencias en el logro de los objetivos de calidad y rendimiento rendimiento del proceso del proyecto.

4

Calidad de Software – Cápsula 16

Siete Herramientas Comunes del CEP. El CEP toma números y los presenta de manera gráfica con el fin de contar una historia. La historia que cuenta demuestra qué está sucediendo al interior del proceso. A esa historia con frecuencia se le llama “La voz del proceso”. Las imágenes generadas deben explicarse y deben ser precisas. A tal fin, hay siete herramientas que se reconocen comúnmente para Control Estadístico de Procesos. 01. Hoja de Revisión o de Verificación (Check sheet). Se usa para contar y acumular datos.

Figura 1.2. Ejemplo de Hoja de Revisión o de Verificación (Check sheet).

5

Calidad de Software – Cápsula 16

02. Diagrama de Ejecución (Run chart). Tal como se muestra en la Figura 3, el diagrama de ejecución rastrea tendencias en un período de tiempo. Los puntos se rastrean en el orden en el que ocurren. Cada punto representa una observación. Con frecuencia se ven tendencias interesantes en los datos con simplemente trazarlos en este diagrama. Un peligro al usar Diagramas de Ejecución es que se puede reaccionar de forma exagerada a las variaciones normales, pero con frecuencia es útil poner los datos en esta clase de diagrama para obtener una “sensación” del comportamiento del proceso.

Figura 1.3. Ejemplo de Diagrama de Ejecución (Run chart). 6

Calidad de Software – Cápsula 16

03. Histograma (Histogram). Tal como se muestra en la Figura 4, el histograma es un diagrama de barras que presenta datos que han sido recolectados en un período de tiempo y los presenta gráficamente por frecuencia. Cada barra representa la cantidad de observaciones que encajan dentro de un rango indicado. Los histogramas son útiles debido a que se pueden usar para ver el monto (o suma) de variación en un proceso. Usando el histograma, se obtiene una perspectiva diferente de los datos. Se puede ver con qué frecuencia ocurren valores similares y tener una idea rápida de cómo se distribuyen los datos.

Figura 1.4. Ejemplo de Histograma. 7

Calidad de Software – Cápsula 16

04. Diagrama de Pareto (Pareto chart). Tal como se muestra en la Figura 5, es un diagrama de barras que presenta datos priorizados siguiendo un criterio establecido, por lo general en orden de importancia ascendente o descendente. Se usan para mostrar datos de atributos. Se denominan atributos a datos cualitativos que se pueden contar para guardarlos y analizarlos, por ejemplo, contando el número de cada tipo de defecto. Los diagramas de Pareto se usan con frecuencia para analizar el tipo de característica que ocurre con mayor frecuencia. Mediante el Diagrama de Pareto se pueden detectar los problemas que tienen más relevancia mediante la aplicación del principio de Pareto (pocos vitales, muchos triviales) que dice que hay muchos problemas de poca importancia frente a solo unos graves. La gráfica es muy útil al permitir identificar visualmente en una sola revisión tales características vitales a las que es importante prestar atención y de esta manera utilizar todos los recursos necesarios para llevar a cabo acciones necesarias sin malgastar esfuerzos.

Figura 1.5. Ejemplo de Diagrama de Pareto (Pareto chart). 8

Calidad de Software – Cápsula 16

05. Diagrama o Gráfico de Dispersión (Scatter diagram/chart). Tal como se muestra en la Figura 6, es un diagrama en el que se dibujan puntos que representan datos, permitiendo observar tendencias entre una variable y otra. Esta clase de diagrama se usa para explorar posibles relaciones “causa-efecto”. Un peligro con este diagrama es que no prueba (o no es suficiente para demostrar) la relación “causa-efecto”.

Figura 1.6. Ejemplo de Diagrama o Gráfico de Dispersión (Scatter diagram/chart). 9

Calidad de Software – Cápsula 16

06. Diagrama de Causa y Efecto o “Espina de Pescado” (Cause and effect or fishbone diagram). Tal como se muestra en la Figura 7, es una representación gráfica de los problemas y sus (posibles) causas. Esta es una buena forma para capturar los aportes generados en reuniones de “lluvia de ideas” a partir de un conjunto de datos (por ejemplo, de defectos) o a partir de una Hoja de Revisión.

Figura 1.7. Ejemplo de Diagrama de Causa y Efecto o “Espina de Pescado” (Cause and effect or fishbone diagram). 10

Calidad de Software – Cápsula 16

Esa herramienta ayuda a identificar las causas de los problemas. Se reconocen varias categorías de causas potenciales que pueden afectar a organizaciones de desarrollo de software y que pueden incluirse en el análisis: (a) Entorno: se incluyen factores externos como contaminación, temperatura del medio ambiente, altura de la ciudad, humedad, ambiente laboral, etc. (b) Talento Humano: se incluyen factores que pueden generar el problema desde el punto de vista del factor humano. Por ejemplo, falta de experiencia, salario, grado de entrenamiento, creatividad, motivación, habilidad, estado de ánimo, etc. (c) Mediciones: se incluyen factores relacionados con deficiencias en la definición de indicadores, escalas, criterios de decisión, recolección de medidas, etc. (d) Herramientas Tecnológicas: se incluyen factores relacionados con las herramientas de desarrollo empleadas, obsolescencia de los equipos, etc. (e) Método: se incluyen factores relacionados con el método de trabajo, por ejemplo: el no seguir de manera correcta un estándar de pruebas, una metodología de desarrollo, estándares de codificación y documentación, etc.

Un aspecto fundamental que debe indicarse en esta guía se refiere a que hay 2 tipos de causas de variación del proceso desde el punto de vista del control estadístico: (a)

Causas especiales. Se caracterizan por ser inusuales, se reflejan en un evento específico y suelen ser pocas en número pero importantes. Algunos ejemplos de causas especiales son: personal enfermo o ausente, cambio intempestivo de un proveedor o de personal, variaciones de energía, computadores defectuosos, fraude en documentación, etc. Este tipo de causas son las que no permiten tener un proceso bajo control y sobre ellas se debe trabajar para eliminarlas.

(b)

Causas comunes. Se caracterizan por hacer parte del proceso y se presentan con frecuencia, son numerosas, su impacto es bajo pero de efecto acumulativo y se les considera difíciles de detectar. Algunos ejemplos de causas comunes son: procedimientos o metodologías inapropiados, carencia de procedimientos estándares de operación definidos con claridad, pobres condiciones de trabajo (iluminación, ruido, temperatura, ventilación), error en el control de calidad, etc. 11

Calidad de Software – Cápsula 16

En resumen, la variación por causas especiales tiene su origen en situaciones que no forman parte de la definición del proceso, es decir, representan una anomalía sobre la que se debe planear y ejecutar acciones para eliminarla.Por ello, una organización debe dar prioridad a acciones encaminadas a eliminar las causas especiales que inciden en el proceso. De otra parte, la variación por causas comunes es inherente al proceso, y se debe a gran cantidad de factores del propio sistema y cada uno de ellos tiene una contribución tan pequeña, que resulta muy costoso localizar cada factor y reducir su variación. Sin embargo, hay que trabajar sobre ellas, una vez eliminadas las causas especiales, para que sea posible transformar el proceso para que esté bajo control estadístico y mejore sus índices de desempeño. Es muy importante que en esta actividad se evite cometer 2 tipos de errores: (a)

Error Tipo 1: tratar un evento como si proviniera de una causa especial, cuando en realidad se debe a causas comunes. Cuando se comete este error, se interviene en el proceso, cuando no hay necesidad y eso significa que se le añade una variabilidad externa que se suma a la variabilidad de causas comunes, y por consiguiente, se empeora el desempeño del proceso. En otras palabras, el Error Tipo 1 ocurre cuando se quiere arreglar algo que no está dañado.

(b)

Error Tipo 2: tratar un evento como si proviniera de causas comunes de variación, cuando en realidad se debe a una causa especial. Cuando se comete este error, el personal no interviene en el proceso, porque piensa que la variabilidad es debida a causas comunes. En otras palabras, el Error Tipo 2 ocurre cuando se debe arreglar algo que está dañado y nada se hace al respecto.

12

Calidad de Software – Cápsula 16

07. Diagramas o Gráficos de Control (Control chart). Esta clase de diagramas, como el que se muestra en la Figura 8, es básicamente un Diagrama de Ejecución (Run chart) al que se le agregan un límite superior y un límite inferior que le permiten a una organización rastrear variaciones en el desempeño de los procesos. También se les llama Diagrama de Comportamiento del Proceso. La gráfica de control es un método gráfico que ayuda a evaluar si un proceso está o no en un estado de control estadístico. Es decir, ver su comportamiento dentro de límites de especificación. Es muy parecida a las gráficas de línea o de tendencias, la diferencia esencial estriba en que las gráficas de control tienen los denominados "límites de control”, que determinan el rango de variabilidad estadística aceptable para la variable que se esté monitoreando. Si los puntos se mantienen dentro de los límites de control y presentan un patrón aleatorio, entonces se dice que "el proceso está en control ", si por el contrario, se encuentran puntos fuera de los límites de control, o el conjunto de puntos muestra tendencias, periodicidad, o cosas anormales, entonces el proceso se diagnostica como inestable, o "fuera de control". Ante una situación de esta naturaleza, debe procederse a investigar las causas que estén provocando esa inestabilidad, e implementar acciones preventivas para evitar que vuelvan a presentarse. Las ventajas de las gráficas de control son: • • • •

Sirve para determinar el estado de control de un proceso. Diagnostica el comportamiento de un proceso en el tiempo. Indica si un proceso ha mejorado o empeorado. Sirve como una herramienta de detección de problemas.

Permite identificar las dos fuentes de variación de un proceso: causas comunes o también llamadas naturales, que se refiere a los factores que afectan en poco la variabilidad del sistema. 13

Calidad de Software – Cápsula 16

Su presencia es aleatoria, y no son de fácil detección, generalmente están relacionadas con aspectos administrativos. Y otras causas son llamadas especiales o asignadas, estas se refieren a los factores esporádicos que desestabilizan el sistema. Su identificación es inmediata y fácil.

Figura 1.8. Ejemplo de Diagrama o Gráfico de Control (Control chart).

14

Calidad de Software – Cápsula 16

En pocas palabras: Clasificación de las herramientas en función de su empleo (Vega, 1999):

Figura 1.9. Esquema de clasificación para las herramientas en SPC según su área 15

Calidad de Software – Cápsula 16

PARTE 2. METODOLOGÍA SIX – SIGMA

1. ¿Qué significa la palabra “Sigma”?

2. ¿Qué es y para qué sirve Six-Sigma? Seis Sigma es una metodología de mejora de procesos, centrada en la reducción de la variabilidad de los mismos, consiguiendo reducir o eliminar los defectos o fallas en la entrega de un producto o servicio al cliente. La meta de 6 Sigma es llegar a un máximo de 3.4 defectos por millón de eventos u oportunidades (DPMO), entendiéndose como defecto cualquier evento en que un producto o servicio no logra cumplir los requisitos del cliente. 16

Calidad de Software – Cápsula 16

Seis sigma utiliza herramientas estadísticas para la caracterización y el estudio de los procesos. Obtener 3.4 defectos en un millón de oportunidades es una meta bastante ambiciosa pero alcanzable. Se puede clasificar la eficiencia de un proceso en base a su nivel de sigma: Nivel de sigma

Porcentaje de Eficiencia

2

69

3

93.3

4

99.38

5

99.977

6

99.99966

17

Calidad de Software – Cápsula 16

Una idea sobre esos porcentajes:

18

Calidad de Software – Cápsula 16

3. Los submodelos de Six-Sigma Seis Sigma alcanza sus objetivos mediante el uso de dos modelos secundarios DMAIC y DMADV o también conocido como DFSS: El modelo DMAIC (Definir, Medir, Analizar, Mejorar, Controlar) busca una mejora incremental para los procesos existentes que están por debajo de la especificación, tiene las siguientes fases secuenciales:  Definir los Problemas: se determina cual de todos los problemas causa más conflictos, cual cuesta más dinero o incomoda más a los clientes.  Medir: valorar la capacidad o competencia del proceso midiendo las posibilidades de que se produzcan errores. Se identifican y documentan los parámetros del proceso que afectan a su rendimiento y a las características del producto.  Analizar: Se analizan los números para averiguar el estado real del proceso, a qué se deben los errores y cómo se pueden evitar.  Mejorar: Se mejorarán los componentes críticos para la calidad que no están a un buen nivel y se fijará una meta razonable. Después de fijarse los estándares numéricos, se calculan las “franjas de tolerancia” que se han de ajustar para mejorar y se determina qué pasos se deben seguir para lograrlo.  Controlar: Se valoran los resultados y se confirman que está dando los frutos deseados. Se diseñan y documentan los controles necesarios para asegurar que los beneficios de los esfuerzos de mejora podrán. 19

Calidad de Software – Cápsula 16

El modelo DMADV (por las siglas en ingles de Definir, Medir, Analizar, Diseñar, Verificar) ó DFSS (por las siglas en inglés de “Diseño Para Seis Sigma”), combina el concepto de planificación de la calidad con el objetivo de Seis Sigma; dirige a los diseñadores del producto alcancen niveles de excelencia. En resumen el proceso de Diseño para Seis Sigma tiene las siguientes cinco fases consecutivas:  Definir: Establece el proyecto como una iniciativa de la organización por solucionar un problema que se encuentra claramente definido y que amerita su solución.  Medir: Identifica los requisitos de los clientes, focalizando las características críticas para la calidad, se valoran su rendimiento y evalúa el riesgo; para esto se soporta por herramientas como el benchmarking, AMFE (Análisis modal de fallos y efectos del proceso) y QFD (Quality Functional Deployment).  Analizar: Seleccionar un diseño de alto nivel de varios diseños alternativos y evaluar la capacidad del diseño seleccionado.  Diseñar: Se basa en el diseño seleccionado en la fase anterior, optimiza los parámetros de diseño a nivel de detalle, planifica pruebas de verificación y verifica el nivel de rendimiento del proceso.  Verificar: Ejecuta pruebas piloto y analiza los resultados, implanta el proceso de producción y realiza las actividades para una transferencia del proceso a los responsables.

20

Calidad de Software – Cápsula 16

4. Six Sigma en el Proceso de Desarrollo de Software Las diferencias fundamentales entre la producción industrial y el desarrollo de software son:

Con estas consideraciones se ha visto que para el proceso de desarrollo de software, será más conveniente emprender con el modelo DMADV (Definir, Medir, Analizar, Diseñar, Verificar) ó DFSS (por las siglas en inglés de “Diseño Para Seis Sigma”), las fases adaptadas al proceso de desarrollo de software se describen a continuación:

21

Calidad de Software – Cápsula 16

 Definir los Problemas: Corresponde revisar detalladamente el historial de los proyectos, poniendo mayor atención en los errores y fallos detectados. Si bien en los ambientes de desarrollo de software se pueden presentar cientos de tipos de errores, pero para la medición se puede tomar como base la clasificación que presentan algunos autores, por ejemplo Pressman en su libro “Ingeniería del Software, un enfoque práctico”, presenta una lista de doce categorías, lo cual facilita la tarea. EIE: Especificación incompleta o errónea. MCC: Mala interpretación de la comunicación del cliente. DDE: Desviación deliberada de la especificación. IEP: Incumplimiento de los estándares de programación. ERD: Error en la representación de los datos. IMI: Interfaz de módulo inconsistente. ELD: Error en la lógica de diseño. PIE: Prueba incompleta o errónea. DII: Documentación imprecisa o incompleta. TLP: Error en la traducción del diseño al lenguaje de programación. IHM: Interfaz hombre-máquina ambigua o inconsistente. VAR: Varios.

Una vez que contamos con datos objetivos (números) se procede a identificar los pocos vitales, es decir, aquellos que han ocasionado conflictos con los clientes, mayor impacto en el costo del proyecto y retraso en las fases del proceso de desarrollo en general, para el efecto se utilizarán las herramientas básicas de calidad. 22

Calidad de Software – Cápsula 16

 Medir: En esta etapa es preciso tener en cuenta que la información numérica es la base de Seis Sigma, las decisiones se basarán en datos fiables, se identificarán a los clientes claves de la fase del proceso de desarrollo de software que queremos mejorar y sus necesidades críticas, todo esto consistentemente definido y documentado.  Analizar: Se desarrollan alternativas de solución, considerando mejoras en la fase o actividad específica del proceso, perfil del personal, metodología, tecnología empleada, herramientas, entorno de trabajo, etc. y luego de un análisis detenido se selecciona la alternativa más adecuada, dejando una descripción de alto nivel de los parámetros de la solución.  Diseñar / Mejorar: En base de las características de alto nivel de la solución se va detallando cada una de éstas, los resultados que se esperan alcanzar y se determina el impacto económico que demandará la implantación de la solución. Se capacita al personal en la solución a implantar y se implanta.  Evaluar / Controlar: Para la valoración de los resultados se planificarán las acciones correspondientes de revisión, verificación y validación, las cuales deben quedar debidamente documentadas; también es importante ir generando los registros correspondientes a fin de contar con información confiable que permita primero evaluar si se está cumpliendo con los objetivos propuestos y en segundo lugar para tener un historial que permita emprender un nuevo ciclo de mejora.

23

Calidad de Software – Cápsula 16

5. ¿Cómo establecer el nivel sigma de un proceso? Para ello se usa el indicador DPMO. Lo que se expresa en esta sección, tiene como fuente a Olofsson (2011). Defectos por Millón de Oportunidades (DPMO) es el número real de defectos observados, extrapolado a cada 1.000.000 de oportunidades. Esto es distinto de “piezas defectuosas por millón” (PPM defectuosas), porque una “pieza” puede tener múltiples “oportunidades” de ser defectuosa. Para calcularlo, se utilizan estas variables: D = número de defectos observados en la muestra U = número de Unidades en la muestra (por ejemplo: 2000 líneas de código) O = Oportunidades por Unidad (cantidad de criterios o clases de prueba). DPMO = (1.000.000 * D) / ( U * O ) Por ejemplo, si se detectan 7 defectos en una muestra de 2.000 LDC, y se manejaran 4 criterios o clases de prueba, el cálculo sería: DPMO = (1.000.000 * 7) / ( 2.000 * 4 ) = 875. 24

Calidad de Software – Cápsula 16

En Seis Sigma el objetivo es lograr que DPMO sea inferior a 3.4. Se puede determinar el nivel de sigma a partir del valor DPMO: Valor DPMO

Nivel de sigma

308537.0

2

66807.0

3

6210.0

4

233.0

5

3.4

6

Tabla 2.1. Nivel de sigma (valores enteros) a partir del valor DPMO. Fuente: De Muro y Ortega (N.D.).

De modo que con los datos de ejemplo, se puede afirmar que el proceso tiene un nivel de sigma igual a 4. Ahora bien, parece que no hay coincidencia para la totalidad de los valores DPMO, como puede observarse en la siguiente tabla:

25

Calidad de Software – Cápsula 16

Valor DPMO Nivel de sigma 308500.0 2.000 226600.0 2.250 158700.0 2.500 105600.0 2.750 66800.0 3.000 40100.0 3.250 22700.0 3.500 12200.0 3.750 6200.0 4.000 3000.0 4.250 1300.0 4.500 600.0 4.750 230.0 5.000 130.0 5.250 30.0 5.500 16.7 5.750 3.4 6.000

Cpk 0.667 0.750 0.833 0.917 1.000 1.083 1.167 1.250 1.333 1.417 1.500 1.583 1.667 1.750 1.833 1.917 2.000

Tabla 2.2. Nivel de sigma a partir del valor DPMO. Fuente: http://www.moresteam.com/toolbox/six-sigma-conversion-table.cfm

Y retomando los valores del ejemplo, el nivel de sigma sería de 4.5. 26

Calidad de Software – Cápsula 16

PARTE 3. PROCESO BAJO CONTROL Y MANEJO DE GRÁFICOS DE CONTROL

Se dice que un proceso está bajo control cuando los valores del gráfico se encuentran dentro de los límites de control y muestran un comportamiento aleatorio dentro de dichos límites. Si algún valor aparece fuera de los límites de control se dice que el proceso se encuentra fuera de control y hay que analizar la causa o causas que han provocado la salida de los límites de control. El gráfico debe analizarse con respecto a la siguiente definición de pruebas, tal como se indica en la Tabla 3.1. Si falla al menos una de las ocho pruebas, se puede decir que el proceso no está bajo control estadístico. Prueba

Definición de la situación anómala

RT1

Tres sigma

1 punto más allá ±3 desviaciones estándar desde la línea central.

RT2

Dos Sigma

2 de 3 puntos consecutivos más allá ±2 desviaciones estándar (pero menor a 3 desviaciones estándar) desde la línea central en el mismo lado.

RT3

Un Sigma

4 de 5 puntos consecutivos más allá ±1 desviación estándar (pero menor a 2 desviaciones estándar) desde la línea central en el mismo lado.

RT4

Ejecución de un mismo lado de la Línea Central

7 puntos consecutivos de un mismo lado de la línea central.

RT5

Mezcla (de procesos) o proceso sobreajustado

8 puntos consecutivos más allá ±1 desviación estándar de la línea central (puede ser de uno o de ambos lados).

RT6

Estratificación

15 puntos consecutivos dentro de 1 desviación estándar de la línea central (puede ser de 1 o de ambos lados).

RT7

Tendencia Oscilatoria

14 puntos consecutivos, alternando arriba y abajo.

RT8

Tendencia Lineal

6 puntos consecutivos, todos crecientes o todos decrecientes.

Tabla 3.1. Definición de Pruebas para un gráfico de control 27

Calidad de Software – Cápsula 16

Esas pautas de comportamiento pueden avisarnos de la aparición de causas especiales antes de que aparezcan valores fuera de los límites de control. Aunque un proceso se mantenga bajo control no indica que sea un proceso correcto, puede estar produciendo fuera de los límites de especificación establecidos por un cliente externo o interno. Pequeño ejemplo. Si se tuvieran estos datos. Producto Tamaño (LDC) 1 721 2 380 3 235 4 506 5 276 6 598 7 642 8 968 9 412 10 717 11 521 12 373 13 811 14 412 15 655 16 520 17 244 18 598 19 848 20 773

1

El cálculo a realizar es: (Defectos) / (Tamaño en KLDC).

Defectos Densidad de Defectos (Defectos/KLDC)1 21 29,126214 11 28,947368 7 29,787234 14 27,667984 8 28,985507 17 28,428094 19 29,595016 28 28,925620 12 29,126214 20 27,894003 15 28,790787 11 29,490617 23 28,360049 12 29,126214 19 29,007634 15 28,846154 7 28,688525 17 28,428094 24 28,301887 22 28,460543 Tabla 3.2. Tabla de datos

Ejemplo producto 1: 21 Defectos / (721/1000) KLDC = 21 Defectos / 0.721 KLDC = 29.126214 Defectos / KLDC 28

Calidad de Software – Cápsula 16

Cuyo gráfico de control es este: 30,000000 Densidad de Defectos

LCS (29.479211)

29,500000

LC + 2 (29.252536)

LC + 1 (29.025862)

29,000000

LC (28.799188) LC – 1 (28.572513)

28,500000 LC – 2 (28.345839)

LCI (28.119165)

28,000000

Sigma = 0.226674

27,500000 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Figura 3.1. Diagrama de dispersión correspondiente con los datos de la Tabla 3.2.

29

Calidad de Software – Cápsula 16

Los resultados obtenidos al aplicar lo indicado en la Tabla 1, se explican en la Tabla 3.

Prueba Resultado

Explicación

RT1

Falla

Superior a 3 desviaciones estándar desde la línea central: Por encima: Productos 3, 7 y 12. Por debajo: productos 4 y 10.

RT2

Aprobada

No hay 2 de 3 puntos consecutivos por encima de 2 desviaciones estándar a partir de la línea central en el mismo lado.

RT3

Aprobada

No hay 4 de 5 puntos consecutivos por encima de 1 desviación estándar a partir de la línea central en el mismo lado.

RT4

Aprobada

Solo hay 4 puntos consecutivos de un mismo lado de la línea central. Esa serie está conformada por los productos 17, 18, 19 y 20.

RT5

Aprobada

Solo hay 3 puntos consecutivos por encima 1 desviación estándar a ambos lados de la línea central (productos 12, 13 y 14; productos 18, 19 y 20).

RT6

Aprobada

Solo hay 3 puntos consecutivos dentro de 1 desviación estándar de la línea central (productos 15, 16 y 17).

RT7

Aprobada

La serie más larga solo tiene 11 puntos consecutivos alternando arriba y abajo. Está dada por los productos del 1 al 11.

RT8

Falla

Hay 6 puntos consecutivos decrecientes (productos 14, 15, 16, 17, 18 y 19). Tabla 3.3. Interpretación de resultados de pruebas

30

Calidad de Software – Cápsula 16

Características del proceso a controlar La característica nos va a indicar el estado del proceso, de ahí su importancia de elegirla correctamente. Las características a controlar pueden ser individuales, como la densidad de defectos, o una variable indicadora que sea promedio ponderado de otras características, como pudiera ser la satisfacción del cliente que fuera suma promediada (ponderada) de varias características. Las características a controlar pueden ser variables continuas o de atributos. Dentro de los procesos de ingeniería de software tenemos como características variables el esfuerzo en proyectos o en el desarrollo de módulos, productos, la productividad, etc. Y como de atributos la densidad de defectos o el número de incidencias detectadas en inspecciones o revisiones. En los procesos es muy importante elegir correctamente la característica o características a controlar. También sería conveniente comenzar con aquellas de las cuales se tengan datos históricos, con el objetivo de crear el gráfico de control de base, que permita saber si un nuevo valor está o no dentro de los límites de control.

31

Calidad de Software – Cápsula 16

Tipos de gráficos de control En función del tipo de característica a representar gráficamente, hay dos tipos de gráficos de control: por variables y por atributos. Gráficos de control por variables. Son los gráficos de control en el que la característica a medir es una variable (expresable numéricamente), y los valores de esta variable se distribuyen según una distribución normal. Se describen tres gráficos de control por variables. Valores individuales (X). El método de cálculo de la línea central y de los límites se muestran en la Tabla 3.4. Medidas y recorridos (X-barra, R). Se usan para monitorear la media y la variabilidad y los subgrupos racionales tienen un tamaño fijo. Constan de dos gráficos: uno para el control de medias y otro de rangos para el control de la variabilidad del proceso. Es un gráfico sencillo de realizar y se puede utilizar con muestras de tamaño pequeño incluso menor que 8. El método de cálculo de la línea central y de los límites se muestra en la Tabla 3.4. Medias y desviaciones típicas (X-barra, S). Se usan para monitorear la media y la variabilidad y los subgrupos racionales tienen un tamaño variable. Es más exacto que el gráfico X-barra, R. Constan de dos gráficos: uno para el control de las medias y otro de desviaciones típicas para el control de la variabilidad del proceso. El indicador de la variabilidad es mejor que el de rangos (recorridos). Se puede utilizar con muestras de cualquier tamaño. El método de cálculo de la línea central y de los límites se muestra en la Tabla 3.4.

32

Calidad de Software – Cápsula 16

La tabla que se presenta aquí agrupa los cálculos de medida central y de los límites para gráficos de control por variables. Cabe anotar que en los tres tipos de gráficos, sus datos siguen la distribución normal. En la tabla 3.4, el parámetro R representa el recorrido (diferencia entre el valor máximo y el valor mínimo de un conjunto de datos). Los parámetros A, B, D se obtienen de las tablas de constantes (Tabla 3.5). Tipo de gráfico por variable

Gráfica X

Gráfica R

Gráfica S

LC   x Valores individuales

LCS   x  A x

LCI   x  A x

A=3

(X-barra, R)

(X-barra, s)

LC = X

LC = R

LCSX = X + A2R

LCSR = D4R

LCIX = X - A2R

LCIR = D3R

LC = X

LC = S

LCSX = X + A3S

LCSS = B4S

LCIX = X - A3S

LCIS = B3S

Tabla 3.4. Cálculos de medida central y límites para gráficos por variables 33

Calidad de Software – Cápsula 16

Tabla 3.5. Tabla de constantes para gráficos por variables 34

Calidad de Software – Cápsula 16

Gráficos de control por atributos. No siempre todas las características se pueden representar mediante valores numéricos. Hay casos en que los productos inspeccionados se deben clasificar como conforme o no conforme respecto de las especificaciones de dicha característica considerada. A estas características se les denomina atributos y describen dos situaciones: (1) El producto desarrollado es conforme (no defectuoso) o no conforme (defectuoso). Cumple con las especificaciones solicitadas o no. Los datos siguen una distribución binomial. (2) El producto puede tener una o más no conformidades (defectos) y el número de estos es determinado. Los datos siguen una distribución de Poisson. El gráfico para este tipo de medida se denomina gráfico de control por atributos. Se utilizan cuatro gráficos en función del atributo a controlar: (a) Gráfico P: porcentaje de productos no conformes o defectuosos encontrados en la muestra seleccionada. El tamaño de la muestra es variable. (b) Gráfico Np: número de productos no conformes o defectuosos encontrados en la muestra seleccionada. El tamaño de la muestra es constante. (c) Gráfico C: número de no conformidades o defectos encontrados en una unidad de producto inspeccionada. El tamaño de la muestra es constante. (d) Gráfico U: número de no conformidades o defectos encontrados en una unidad de producto inspeccionada. El tamaño de la muestra es variable. El método de cálculo de la línea central y de los límites se muestra en la Tabla 6, donde N = Tamaño de la muestra n = media del tamaño de las muestras. n = (n1 + n2 + n3 + … + nn) / N Los gráficos de control por atributos requieren tamaños de muestras grandes (mayores de 50) con el objetivo de detectar cambios. 35

Calidad de Software – Cápsula 16

Tipo de gráfico

P

Np

Tamaño muestra

Variable

Constante

Línea Central

Límites

p=∑p/N

LCS = p + 3√( p ( 1 - p ) / n )

LC = p

LCI = p

LC = np

U

C

Variable

Constante

Binomial p (1- p )/ n )

LCS = p + 3√( np ( 1 - p ) ) LCI = p

u=∑u/N

- 3√(

-

3√( np ( 1 - p ) )

LCS = u + 3√( u / n )

- 3√(

LC = u

LCI = u

c=∑c/N

LCS = c + 3√ c

LC = c

LCI = c

- 3√

Distribución datos

u /n )

Binomial

Poisson

Poisson

c

Tabla 3.6. Cálculos de medida central y límites para gráficos por atributos

36

Calidad de Software – Cápsula 16

Construcción de un gráfico de control. Los pasos a seguir para la realización de un gráfico de control son los siguientes: (1)

Elección de la característica a controlar.

(2)

Toma de datos de la característica elegida.

(3)

Elección del tipo de gráfica.

(4)

Cálculo de la media de los valores.

(5)

Cálculo de los límites de control.

(6)

Definir la escala del gráfico, dibujar la línea central y los límites de control y representar los valores de la característica medida.

(7)

Análisis del gráfico de control.

En el caso de que fuera la primera gráfica de control (que se elabora), si hay algún valor fuera de los límites de control, se elimina de la lista de valores y se vuelve al paso 4 para calcular la nueva media y los nuevos valores de los límites de control, así tantas veces como puntos de control se encuentren. ES DECIR, SE HACE UNA VEZ PARA CADA PUNTO. Cuando ya no haya ningún punto fuera de control, se dirá que los valores representan al proceso bajo control y servirá de base para los nuevos datos que se vayan introduciendo con el objetivo de ver si estos nuevos valores se encuentran o no bajo control.

37

Calidad de Software – Cápsula 16

Ejemplo de construcción de un gráfico de control por variable Se desea conocer el estado de la productividad de los proyectos del año. Durante el año ha habido 8 proyectos y han participado como mínimo cuatro programadores. La siguiente tabla muestra la productividad media (en Líneas de código –efectivas y probadas– por día) de programadores en diferentes proyectos. P1

P2

P3

P4

P5

P6

P7

P8

Prog1

6.00

5.71

8.33

5.75

10.00

5.00

10.00

5.75

Prog2

10.00

7.78

8.50

8.82

7.78

5.71

8.50

8.82

Prog3

17.14

13.33

5.40

8.75

12.00

13.33

5.40

10.00

Prog4

11.78

4.00

10.53

9.74

17.67

4.00

10.53

9.74

El tipo de gráfico seleccionado es el “gráfico de control de variables X-barra, R”. (Muestras tamaño fijo). Primero se calcula la media Xi y el rango o recorrido de cada uno de los subgrupos. P1

P2

P3

P4

P5

P6

P7

P8

Medias

11.23

7.71

8.19

8.27

11.86

7.01

8.61

8.58

Total = 71.45

Rangos

11.14

9.33

5.13

3.99

9.89

9.33

5.13

4.25

Total = 58.19

38

Calidad de Software – Cápsula 16

Se calcula la línea central LC para X

∑ (xi / N) R = ∑ (Ri / N)

y para R.

LC X =

siendo N el tamaño de la muestra

LC

siendo N el tamaño de la muestra

Para el ejemplo: LC X = (71.45 / 8) = 8.93125

LC R = (58.19 / 8) = 7.27375

Cálculo de los Límites de Control LCS X = X + A2 R

LCI X = X - A2 R N

Desviación estándar (para gráfico X) SD  LCS R = D4 R

(X i 1

i

 X )2

N



20.29466  1.59274 8

LCI R = D3 R

Sigma (σ) = R / d2(n) σ = 7.27375 / 2.059 σ = 3.53266

Los valores de A2, D4 y D3 se obtienen de la tabla de constantes (Tabla 5). Para el ejemplo: en una muestra de tamaño 4, el valor A2 es de 0.729, el valor D4 es 2.282 y el valor D3 es 0. LCS X = 8.93125 + (0.729 * 7.27375) = 14.23381

LCI X = 8.93125 - (0.729 * 7.27375) = 3.62868

LCS R = 2.282 * 7.27375 = 16.59869

LCI R = 0 * 7.27375 = 0 39

Calidad de Software – Cápsula 16

Las gráficas resultantes son: 16,00

Gráfico Xbarra para Productividad LCS X = 14.23381

Productividad Media (LDC/dia)

14,00 12,00 10,00

8,00 6,00

LC X +2SD LC X +1SD LC X = 8.93125 LC X - 1SD LC X - 2SD

4,00

LCI X = 3.62868

2,00

Proyectos

0,00 0

1

2

3

4

5

6

7

8

9

Evaluación: Explicación

Prueba RT1:Tres sigma

Aprobada

NO HAY puntos más allá de ±3 desviaciones estándar (SD) desde la línea central

RT2: Dos sigma

Aprobada

NO HAY 2 de 3 puntos consecutivos más allá de ± 2 SD desde la línea central en el mismo lado

RT3: Un sigma

Aprobada

NO HAY 4 de 5 puntos consecutivos más allá de ± 1 SD desde la línea central en el mismo lado

RT4: Secuencia mismo lado LC

Aprobada

NO HAY 7 puntos consecutivos de un mismo lado de la línea central

RT5: Mezcla / Sobreajuste

Aprobada

NO HAY 8 puntos consecutivos más allá ±1 SD de la línea central (de 1 o de ambos lados)

RT6: Estratificación

Aprobada

NO HAY 15 puntos consecutivos dentro de 1 SD de la línea central (de 1 o de ambos lados)

RT7: Tendencia oscilatoria

Aprobada

NO HAY 14 puntos consecutivos alternando arriba y abajo

RT8: Tendencia lineal

Aprobada

NO HAY 6 puntos consecutivos crecientes o decrecientes

El proceso está bajo control 40

Calidad de Software – Cápsula 16

Gráfico R para evaluar variación de Productividad

18,00

LCS R = 16.59870

16,00

LC R +2Sigma

Media de Rango por proyecto (LDC/dia)

14,00 12,00 10,00 8,00 6,00

LC R +1S Sigma

LC R = 7.27375

4,00

LC R – 1Sigma

2,00

LC R – 2Sigma 0,00 0

1

2

3

4

5

6

7

8

LCI R = 0 9

Proyectos

Evaluación: Explicación

Prueba RT1:Tres sigma

Aprobada

NO HAY puntos más allá de ±3 desviaciones estándar (SD) desde la línea central

RT2: Dos sigma

Aprobada

NO HAY 2 de 3 puntos consecutivos más allá de ± 2 SD desde la línea central en el mismo lado

RT3: Un sigma

Aprobada

NO HAY 4 de 5 puntos consecutivos más allá de ± 1 SD desde la línea central en el mismo lado

RT4: Secuencia mismo lado LC

Aprobada

NO HAY 7 puntos consecutivos de un mismo lado de la línea central

RT5: Mezcla / Sobreajuste

Aprobada

NO HAY 8 puntos consecutivos más allá ±1 SD de la línea central (de 1 o de ambos lados)

RT6: Estratificación

Aprobada

NO HAY 15 puntos consecutivos dentro de 1 SD de la línea central (de 1 o de ambos lados)

RT7: Tendencia oscilatoria

Aprobada

NO HAY 14 puntos consecutivos alternando arriba y abajo

RT8: Tendencia lineal

Aprobada

NO HAY 6 puntos consecutivos crecientes o decrecientes

El proceso está bajo control 41

Calidad de Software – Cápsula 16

Ejemplo de construcción de un gráfico de control por atributos Se desea comprobar si el número de incidencias por módulo de diferentes proyectos de una organización de desarrollo se encuentra bajo control. La tabla siguiente muestra por cada proyecto una muestra de módulos seleccionados y el número de incidencias que se han encontrado en los módulos. Un módulo puede tener más de una incidencia. El tipo de gráfico a utilizar es el “gráfico de control de disconformidades por unidad (u)” dado que pueden aparecer varias no conformidades independientes en una unidad de producto o servicio (módulo).

Muestra ó Módulos Total Proyecto verificados incidencias 1 12 12 2 14 10 3 16 16 4 20 22 5 14 8 6 17 10 7 14 18 8 15 12 9 18 14 10 16 15 11 12 12 12 13 14 13 15 10 14 17 16 15 12 14 16 14 8 17 15 10 18 16 14 19 15 16 20 12 12 Total 297 263

Incidencias / Módulo 1,00 0,71 1,00 1,10 0,57 0,59 1,29 0,80 0,78 0,94 1,00 1,08 0,67 0,94 1,17 0,57 0,67 0,88 1,07 1,00 17,81

42

Calidad de Software – Cápsula 16

Posteriormente se calcula la línea central LC. Para ello primeramente hay que calcular el número de incidencias por módulo. u = (Suma disconformidades de la muestra) / n Donde n es el número de muestras. Para el ejemplo:

u = 17.81 / 20 = 0.8905

Cálculo de los límites de control: LCS = u + 3√( u / n )

LCI = u

- 3√(

u /n )

Para el ejemplo: n = 297 / 20 = 14.85 LCS = 0.8905 + 3

√ (0.8905 / 14.85)

= 0.8905 + (3 * 0.24488) = 1.62514

LCI = 0.8905 - 3

√ (0.8905 / 14.85)

= 0.8905 - (3 * 0.24488) = 0.15586

43

Calidad de Software – Cápsula 16

La gráfica resultante es: Gráfico de control de disconformidades por unidad (u)

1,80

LCS = 1.62486

1,40

LC +2SD

Incidencias / Módulo

1,60

1,20 1,00 0,80 0,60 0,40

LC +1SD LC = 0.8905 LC - 1SD LC - 2SD

0,20

LCI = 0.15586

0,00 0

2

4

6

8

10

12

14

16

18

20

Proyectos

Evaluación: Explicación

Prueba RT1:Tres sigma

Aprobada

NO HAY puntos más allá de ±3 desviaciones estándar (SD) desde la línea central

RT2: Dos sigma

Aprobada

NO HAY 2 de 3 puntos consecutivos más allá de ± 2 SD desde la línea central en el mismo lado

RT3: Un sigma

Aprobada

NO HAY 4 de 5 puntos consecutivos más allá de ± 1 SD desde la línea central en el mismo lado

RT4: Secuencia mismo lado LC

Aprobada

NO HAY 7 puntos consecutivos de un mismo lado de la línea central

RT5: Mezcla / Sobreajuste

Aprobada

NO HAY 8 puntos consecutivos más allá ±1 SD de la línea central (de 1 o de ambos lados)

RT6: Estratificación

Aprobada

NO HAY 15 puntos consecutivos dentro de 1 SD de la línea central (de 1 o de ambos lados)

RT7: Tendencia oscilatoria

Aprobada

NO HAY 14 puntos consecutivos alternando arriba y abajo

RT8: Tendencia lineal

Aprobada

NO HAY 6 puntos consecutivos crecientes o decrecientes

El proceso está bajo control 44

Calidad de Software – Cápsula 16

REFERENCIAS De Muro, F. y Ortega, P. (N.D.). Presentación 6 Sigma aplicado a la ingenieria de mantenimiento. En: http://pmlconsultores.com.ar/documentacion Herdoiza, V., Jimenez, M. y Otros (N.D.). Presentación sobre Six Sigma. Sistema de Gestión de Calidad. Escuela Superior Politécnica del Litoral. En: http://www.slideshare.net/mayita14/six-sigma-presentation-706895 Hinojosa Raza, C.M. (2008). Seis Sigma y el Proceso de Desarrollo de Software. ESPE 2008. Tercer Congreso de Ciencia y Tecnología. Departamento de Ciencias de la Computación. Escuela Politécnica del Ejército de Ecuador. ISO/TR 10017:2003. Orientación sobre las técnicas estadísticas para la Norma ISO 9001:2000. En: http://es.scribd.com/doc/42023516/ISO-TR-10017-2003-Tecnicas-estadisticas-Espanol Kulpa, M. K., Johnson, K. A. (2008). Interpreting the CMMI: a process improvement approach. Second Edition. ISBN 978‑1‑4200‑6052‑2. pp. 237242. Olofsson, O. (2011). Calculador del Nivel Sigma y de DPMO. En: http://world-class-manufacturing.com/es/Sigma/level.html Sánchez, J. L. (2008). Control Estadístico de Procesos. En libro: Medición y estimación del software. Editores: Piattini Velthuis, Mario; García Rubio, Félix; Garzás Parra, Javier; Genero Bocco, Marcela. Alfaomega Ra-Ma. pp 173-189. ISBN:978-970-15-1413-9. Vega, J.A. (1999). Las Siete Herramientas Básicas de la Calidad. Diplomado en Calidad en el Software. --------------------- FIN DEL DOCUMENTO

45