AUTOMATIZACIÓN DE LA GESTIÓN DE LA CALIDAD DE UNA ORGANIZACIÓN DE SOFTWARE PARTIENDO DE LA MEDICION DEL TAMAÑO Y TOMANDO COMO PRINCIPIO LA SATISFACCIÓN DEL CLIENTE. Autores: Lic. Dialys Aliaska Consuegra Rodríguez (1) Lic. Ronald Shelton Nadal (2) Dra. Ana María García Pérez (3) (1) dialys@dcitma.vlc.cu Delegación Provincial del CITMA. Santa Clara. (2) rshncu@gmail.com Departamento de Tecnologías de la Información. Hospital General Juan Bruno Zayas Alfonso. Santiago de Cuba. (3) anamaria@uclv.edu.cu Centro de Estudios de Informática. Universidad Central de Las Villas Martha Abreu UCLV. Santa Clara. Resumen: El trabajo recoge el estudio de la problemática de la Gestión de la Calidad relativos a la definición de métricas de tamaño en el ámbito de la Ingeniería del Software, mostrando la necesidad de contar con métodos y sistemas de medición y evaluación robustos, teniendo en cuenta ante todo la satisfacción del cliente, planteando además un cambio en el proceso de recolección y análisis de indicadores de productividad y calidad de una empresa de software necesario para que las mediciones resulten mas objetivas, precisas, repetibles, reproducibles y significativas.
2 Introducción: La calidad del software ha sido tema de discusión en los últimos años debido justamente a los problemas de su carencia en cada área de aplicación. Modelos para la evaluación, certificación y gestión de la calidad se han desarrollado, tales como ISO [1] y CMM [2] y modelos de proceso como RUP[3] y CATALYSIS [4] pero aun subsiste la ausencia de mecanismos de control y medición de la productividad que: Sean adecuados a los ambientes de desarrollo actuales, independientes del tipo de la aplicación Midan la satisfacción del cliente, como principal criterio de calidad, y cuánto avanzamos en esta satisfacción Nos ayuden a comprender los verdaderos factores económicos de la producción del software, relativos a cuánto VALOR pueden crear las aplicaciones para los clientes. En el campo de la programación por computadoras, ha sido una realidad la falta de precisión y la ambigüedad en las unidades de medida de calidad y productividad, sin embargo se reconoce que el progreso científico en cualquier campo es totalmente dependiente de la habilidad de medir cantidades en forma precisa. Ishikawa en Que es el control total de calidad? [5] menciona los pasos a seguir: Determinar la unidad de garantía Determinar el método de medición de estas unidades Clasificar los defectos usando adjetivos: crítico, grande, menor, etc. Llegar a un consenso sobre defectos y fallas Revelar los defectos latentes: no paso directo por la cadena de producción, sino vueltas atrás Observar la calidad estadísticamente Llevar la calidad del diseño a la par que la calidad de la aceptación Parafraseando a Ishikawa, el problema radica en encontrar, para el software, la medida del saco en lugar del granito de arroz...para medir lo producido, en otros términos, encontrar la UNIDAD DE GARANTIA DE CALIDAD. La forma de dimensionar, tanto los productos, como los proyectos y el proceso en si, es un tema verdaderamente interesante y el logro de resultados en este sentido puede constituir un fuerte impulso para la gestión de la calidad en la industria del software actual.
3 Una forma efectiva de medir el esfuerzo realizado o el requerido para futuros programas redundará en una planificación temporal y de recursos que se adapte al problema objeto de solución computacional. Las métricas para tamaño del software. Varias escuelas han emergido en el intento de definir una medida de tamaño para el software, las que respetan las líneas de código, las que analizan subelementos de estas líneas separadamente [6] (operadores/operandos), así como las que abandonan las líneas completamente para caer en las funciones [7], los objetos [8] y hasta los casos de uso [9]. El temprano trabajo de Jones [10] es un excelente artículo donde aparecen reflejadas las principales dificultades de las líneas de código como medida y lo paradójica que resulta esta métrica como criterio de productividad. Ya en este trabajo se enuncia que...el desarrollo de un producto de software no solo consiste de tareas de codificación y estas tareas también deberían ser medidas. Sin embargo, a nuestro juicio, un enfoque dirigido a unidades de trabajo, subtareas o completamiento de fases en el ciclo de vida no es tampoco la solución que buscamos si queremos que la medida cumpla los requerimientos enunciados en el epígrafe anterior. La medición de la productividad en los ambientes actuales es una tarea compleja pues debería servir para reflejar el costo de cambiar un programa cuando las circunstancias cambian y reflejar los costos acumulados de una versión simple de programa. El objetivo principal de la mejora del proceso de obtención de versiones de programas es bajar el costo del desarrollo por medio de un incremento de la velocidad en el logro de la satisfacción de las necesidades de los clientes. No puede ser simplemente velocidad de desarrollo en forma absoluta, sino relativa a la satisfacción plena de la necesidad que da origen al desarrollo del producto software. La cantidad de retrabajo o vueltas atrás en el proceso deberá ser minimizada. Hoy en día la tecnología que nos apoya en este camino lo hace en el sentido puramente técnico, como tecnología dura, pero la tecnología blanda está por definir. El costo por defecto, sin una medida que tome en cuenta la satisfacción del cliente, solo producirá errores de interpretación que conducen a una gestión no efectiva de la calidad. Establecer una medida de tamaño Standard tiene las siguientes ventajas:
4 Comparabilidad Al utilizarse la misma métrica en todos los proyectos, se pueden realizar comparaciones entre ellos, y mejor aún, si es una métrica estándar en la industria, podría compararse ésta contra otras. Administrar la productividad Si tenemos el tamaño y por otro lado el esfuerzo Requeridos, entonces es posible establecer indicadores de productividad. Este indicador puede servir para controlar un plan de mejora. Administración de calidad De manera similar si tenemos el tamaño y el número de defectos que se entregaron en un desarrollo, entonces se pueden establecer indicadores de calidad. Con una historia suficiente de proyectos, se pueden estimar proyectos futuros. Valuar el SW de una organización Una vez que se tiene el tamaño de cada aplicación dentro de la organización, es posible evaluar mejor los activos disponibles. Objetivos de la investigación Se tiene como meta la propuesta y validación de una métrica de tamaño de componentes bajo control de configuración, cuyo aspecto fundamental será el tener en cuenta la satisfacción del cliente (cuestión que no se mide en las métricas en uso actualmente). Esta métrica se validará mediante su implantación en diferentes grupos de desarrollo de software, usando una herramienta automatizada para la recolección de los indicadores de producción y calidad. El hecho de obtener estos indicadores de manera automatizada y usando esta nueva métrica, posibilitará el estudio de indicadores más confiables, utilizando otra herramienta automatizada para ello, lo cual permitirá encontrar, a través de estudios estadísticos, una unidad de garantía de la calidad, unidad que en este momento no existe para medir la cantidad de producción de software de una empresa. Debido a la ausencia de mecanismos automáticos de gestión del proceso software basados en el tamaño, el desarrollo de las herramientas para apoyar esta investigación apunta hacia la obtención de un flujo de trabajo, no existente en estos momentos en las prácticas de la ingeniería de software. Este flujo comenzará y terminará en el cliente; desde que hace un pedido de software a la empresa hasta que la empresa le hace la entrega del producto software.
5 Se propone brindar la posibilidad de realizar la recolección automatizada de los tamaños de los componentes bajo control de configuración, aspecto que permitirá a la empresa tener conocimiento constantemente de las medidas de los componentes de software sin obstruir el trabajo de los programadores. Como consecuencia directa de la automatización de la recolección, dado que esta estandarización lo haría más confiable, también se lograría una mejora sustancial en el análisis de los indicadores, primordial para la organización, pues posibilita hacer el análisis de predicción frente a cada pedido de software. Hasta el momento se han desarrollado herramientas para la recolección manual de los indicadores de productividad y calidad de empresas de Software, las más conocidas son: PSP: Personal Software Process; es usado por los ingenieros de software para recolectar y analizar datos sobre su trabajo. Los estudios publicados generalmente usan datos recolectados usando PSP para esbozar las conclusiones cuantitativas sobre el impacto en el comportamiento de los programadores y la calidad del producto. [11] TSP: Team Software Process; es un proceso para equipos de 2 a 20 ingenieros de software entrenados en el uso de PSP. El desarrollo de TSP comenzó en 1996 aunque la herramienta estuvo disponible a finales del 2000. [12] Se han desarrollado otras herramientas a nivel académico que automatizan parcialmente el proceso de recolección y análisis de los indicadores de productividad y calidad, entre ellas podemos mencionar HackyStat, desarrollada en la universidad de Honolulu, la cual automatiza parcialmente el proceso de recolección. El enfoque actual de recolección y análisis de indicadores, al realizarse manualmente, tiene sus repercusiones en tiempo, pues consume a los programadores parte del tiempo de desarrollo. Además implica disparidades en las interpretaciones de las métricas dado que cada programador interpreta las métricas a su manera. El nuevo enfoque automatizado que propone esta investigación implica un cambio en la concepción de las tareas de los desarrolladores, pues desaparece para ellos la responsabilidad de analizar la métrica y recolectar los indicadores. Además este nuevo enfoque permite a los gerentes de proyecto, hacer la predicción de tiempo y recursos de una manera más estándar e independiente y a partir de indicadores más confiables. En general esta investigación plantea un cambio en el proceso de recolección y análisis de indicadores de productividad y calidad de una empresa de software.
6 Este trabajo propone diseñar, implementar y validar un proceso automático de formación de los indicadores de productividad y costo, a partir de la producción de componentes de la organización de software. Para lograr esto será necesario crear una herramienta que calcule una métrica para tamaño del software, acoplable a un sistema de gestión de configuración. Una vez que se cuente con esta herramienta podremos validar la métrica para tamaño de software, a fin de determinar una unidad de garantía de calidad en una amplia gama de proyectos. Luego se propone una herramienta para gestión de indicadores de productividad y costo, acoplable a la gestión de la configuración. De manera general nuestra solución está basada en el diseño e implementación de un marco de trabajo conformado por un conjunto de herramientas y el determinado flujo de información entre ellas. (Ver Figura 1). Para mayor compresión de este diagrama, representamos los procesos de manera general por círculos, las herramientas que planificamos implementar por rombos y los sistemas ya existentes por rectángulos. Dentro de este marco el flujo comenzará y terminará en el cliente; desde que éste hace un pedido de software a la organización hasta que se le hace la entrega del producto. Dimensión del Problema. En este proceso, como bien indica su nombre, el objetivo fundamental será dimensionar el problema a resolver dada la petición del cliente. Este módulo usa como información principal las métricas e indicadores obtenidos de proyectos anteriores e implementa técnicas de Inteligencia Artificial para la toma de decisiones, a fin de brindar datos importantes en la estimación de tiempo y recursos. Información altamente valiosa en el momento de la planificación de nuevos proyectos, justo donde podríamos lograr evitar incumplimientos de los planes de producción trazados. Recolector de Métricas. Este artefacto mediará entre la Producción y la Gestión de Configuración, donde la información recolectada formará parte también de los datos guardados por el Sistema de Gestión de Configuración de Software. Estos datos serán manejados de manera muy útil para calcular la Dimensión del Problema. Tablero de Mando. Herramienta que le facilitará al líder de proyecto y a los directivos tener una visión clara y abarcadora del avance del proceso. Aquí se podrán apreciar indicadores a nivel de proyecto así como índices globales de la empresa tales como los índices de defectos reportados por los clientes y los índices de productividad y de costos.
Figura 1. Flujo de Trabajo del Marco Propuesto. 7
8 Conclusiones Esta investigación se lleva a cabo en el Centro de Estudios de Informática, Universidad Central de Las Villas. En la medida de su avance, sus resultados se pondrán a prueba en equipos de desarrollo de manera que se logre su correcta validación. En si este trabajo se propone mejorar el proceso de desarrollo de software. Todo esto se traducirá en un mayor poder de abarcamiento de pedidos y acometimiento en fecha y con calidad, lo cual derivará en el aceleramiento de la informatización y el mejoramiento del resto de las esferas económica, social, política y académica. Las bondades que propone esta investigación constituirían un arma poderosa para el desarrollo de una empresa e incluso para lograr su certificación según las normas ISO o CMM. Las grandes empresas de software en el mundo, actualmente certificadas, poseen herramientas de este tipo pero no son publicadas puesto que constituyen un arma para elevar la ventaja contra el resto de la competencia.
9 Referencias [1] Paulk, Mark C.; Curtis Bill; Chrissis, Mary Beth; Weber, Charles V. Capability Maturity Model for Software, Version 1.1, CMU/SEI-93-TR-24, Febrero 1993. [2] ISO 8402 Quality Management and Quality Assurance - Vocabulary, International Organization for Standarization, 1994. [3] Rational Unified Process 2000. Copyright 1987-2000 Rational Software Corporation. [4] D Souza, D., Wills, Allan C. Objects, Components and Frameworks with UML. The Catalysis SM Approach. Addison Wesley Longman, Inc. 1998. [5] Ishikawa,K. Qué es control total de la calidad?. La modalidad japonesa. Editora Revolucionaria, La Habana, 1988. [6] Halstead, M. Elements of Software Science. North Holland, 1977. [7] Albretch, A. J. Measuring Application Development Productivity. Proc. IBM Application Development Symposium, Monterrey, CA, octubre 1979, pags. 83-92. [8] Boehm, B., Clark,B., Horowitz, E., Westland, C., Madachy,R., Selby, R. Cost Models for future life cycle processes: COCOMO 2. Annals of Software Engineering, 1, 57-94, Caps. 23 y 27. [9] Sparks, S., Kapczynsky, K. The art of sizing projects: four steps to on-time, onbudget delivery. En http://www.sunworld.com/swol-12-itarchitect.html Octubre 2000. [10] Jones, C. Programming Productivity, Mc Graw Hill, 1986. [11] Watts S. Humphrey. Introducción al proceso de software personal. Addison Wesley. Pearson Educación, España, 2001. [12] Montes de Oca, Cesar. Team Software Process (TSP): Integración de equipos de desarrollo de alto rendimiento. Conferencia. Carnegie Mellon University, 2004.
10