Estrategias de calidad para PYMES de desarrollo de software

3. Gestión de calidad del software
4. Las normas ISO 9000:2000
5. Estrategia para la aplicación de la ISO 9000:2000 aplicada a PYMES de Software
6. Conclusiones
7. Bibliografía

Introducción

A lo largo del tiempo el concepto de calidad ha adquirido un carácter multidimensional, debido a que los diferentes autores, conocidos como los gurús del tema, lo han enfocado desde puntos de vistas diferentes: Deming, como el grado predecible de uniformidad y conformidad a un bajo costo que se ajuste a las necesidades del mercado; Crosby, como cumplir con los requisitos; Feigenbaum, como el conjunto total de las características del producto de marketing, ingeniería, fabricación y mantenimiento a través del cual el producto en uso satisfará las expectativas del cliente y Jurán, como la idoneidad o aptitud para el uso.

En todas estas definiciones se valoran elementos comunes como la satisfacción de necesidades o perspectivas del cliente y la existencia de rasgos o requisitos para satisfacerlas.

Para alcanzarla se ha decursado por varios estadios, comenzando con la verificación y terminando en la calidad total, pasando por el control y el aseguramiento de la calidad. La tendencia internacional actual está fundamentada en la aplicación y certificación sobre la base de las normas ISO 9000 que suponen un lenguaje común, adoptado ya por un elevado número de países.

De ahí, que se pueda considerar como el concepto más actual de calidad el definido por la ISO 9000:2000 , que la define como grado en el que un conjunto de características inherentes cumplen con los requisitos.

Además de las normas ISO 9000, para lograr una efectiva gestión de la calidad en determinados sectores es necesario compatibilizarlas con otras normas específicas adecuadas al tipo de actividad que desarrollan. Tal es el caso de las empresas de la industria del software donde se usan metodologías tan extendidas como el CMM y la ISO SPICE, entre otros modelos.

Finalmente, la naturaleza intangible de este negocio y el hecho de que el software constituye un producto del conocimiento de difícil estandarización, hace necesaria la aplicación de otros modelos que prevén la inclusión de la gestión del conocimiento y su integración a los modelos de calidad, como es el caso del EFQM de Excelencia, base del Premio Europeo de Calidad.

Ante esta abundancia de modelos teóricos y de normas de certificación las pequeñas empresas de software o las principiantes se ven ante el dilema de cuál es el mejor camino a escoger, el más rápido y menos costoso que le permita asegurar la calidad de su productos.

En este trabajo se propone una estrategia concreta que pretende esclarecer los conceptos y trazar un camino para este tipo de empresas en aras de la difícil meta de la calidad.

1. La calidad del software es definida por Pressman (1998) como la concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados y con las características implícitas que se esperan de todo software desarrollado profesionalmente.

   A partir de esta definición vale la pena señalar que no sólo afecta la calidad el incumplimiento de los requisitos del cliente y los explícitamente definidos por la ingeniería de software, sino que los requisitos implícitos también deben ser considerados. Téngase en cuenta que pocas veces el cliente está en condiciones reales de explicitar todo lo que se puede esperar del producto, muchas veces por desconocimiento y otras por la asunción tácita de muchas funcionalidades.

   La gestión de la calidad se puede entender como el conjunto de actividades y medios necesarios para definir e implementar un sistema de la calidad, por una parte y responsabilizarse de su control, aseguramiento y mejora continua, por otra. (Fernández & Alarcón, 1999). El control está dirigido al cumplimiento de requisitos, el aseguramiento a inspirar confianza en que se cumplirá el requisito pertinente y el mejoramiento al aumento de su eficiencia y eficacia.

   La gestión de calidad a nivel de la organización en entidades de software ha seguido dos líneas que pueden perfectamente complementarse entre sí. Por una parte, se ha seguido la línea marcada por las entidades internacionales de estandarización para todos los productos y servicios a través de las normas ISO 9000 y por otra, el mundo del software ha creado su propia línea de trabajo en la gestión de la calidad, trabajando sobre los procesos de producción de software como medio de asegurar la calidad del producto final.

   Cuando los estándares de calidad se orientaban sobre todo al control, en las organizaciones dedicadas al software aparecen un grupo de modelos específicos con ese fin: Modelo de Boehm [Boehm et al., 1978], Modelo FCM (Factors/Criteria/Metrics) [McCall et al., 1977], Marco ISO 9126 [ISO/IEC, 1991], Paradigma GQM (Goal-Question-Metric) [Basili y Rombach, 1988], Modelo de Gilb [Gilb, 1988].

   En los últimos años en que los estándares de calidad internacionales se han reorientado hacia el aseguramiento de la calidad, han aparecido en la industria del software dos importantes modelos de referencia que tienen en común la evaluación de la capacidad de los procesos en niveles de desarrollo o madurez: Modelo CMM (Capability Maturity Model) [Paulk, 1993] y Modelo SPICE (Software Process Improvement and Capability determination) [Rout, 1995], [SPICE, 1999].

   Estadísticas del Software Engineering Institute (SEI) reportan que del total de empresas que aplican CMM el 81 % se encuentra en el nivel 1, el 12 % en el nivel 2 y el 7 % en el nivel 3. Ninguna ha alcanzado los niveles 4 y 5. (Tinnirello, 1998). Esto da cuenta de la rigurosidad del modelo y de las pocas posibilidades que tendría las PYMES de ubicarse en los niveles superiores.

   Las grandes empresas ya consolidadas pueden disponer a su voluntad, y de hecho lo hacen, la implantación de otras metodologías o esquemas propios para lograr la calidad y la mejora continua de sus procesos productivos, sin embargo, para las pequeñas y medianas empresas de software la implantación de sistemas de la calidad basados en las normas ISO 9000 puede constituir el mejor camino a seguir pues estas normas definen los requisitos básicos de la organización y por otro lado la certificación le confiere un prestigio importante ante sus clientes.

   La solución ideal para los que comienzan es integrar ambos enfoques en la medida de los posible bajo el principio de especificar en la ISO 9000 todas aquellas características propias del producto de software que se contemplan en las otras metodologías.

2. Gestión de calidad del software.
3. Las normas ISO 9000:2000.

En 1947 se creó la International Organization for Standartization, que es una federación mundial de organismos nacionales de normalización, cuya sede actual está en Ginebra.

En 1987 se publicaron por primera vez la familia de normas ISO 9000 para el aseguramiento de la calidad, compuesta por la norma ISO 8402: Vocabulario, la norma ISO 9000: Directrices para la selección de los modelos para el aseguramiento de la calidad y los tres modelos ISO 9001, 9002 y 9003 que planteaban los requisitos para los sistemas de calidad aplicables a empresas cuya actividad se enmarcaba en determinadas etapas del ciclo de vida del producto. Además apareció el modelo ISO 9004 dirigido al aseguramiento de la calidad en el orden interno.

En el año 1994 se realizó una revisión de estas normas y se introdujeron algunos cambios que no variaron de manera sustancial la estructura original de la familia del año1987 , y en el año 2000 apareció la última versión (vigente en la actualidad) en la cual se introdujo el enfoque de procesos y los tres modelos (ISO 9001, ISO 9002 e ISO 9003) se unieron en el modelo ISO 9001:2000 aplicable a cualquier organización. Además la norma ISO 8402 se sustituyó por la ISO 9000: Vocabulario y la ISO 9004 se convirtió en el modelo para la mejora del desempeño. La otra integrante de la familia ISO 9000 (norma ISO 19011 para Auditorias de los sistemas de gestión de la calidad y medioambientales) amplió su alcance y se compatibilizó con las ISO 14 000.

¿Qué son las normas ISO?

Un conjunto de normas internacionales genéricas que establecen sistemas de gestión de la calidad aplicados por organizaciones de cualquier tipo o tamaño que fabrican productos o componentes (hardware) ,fabrican software, fabrican materiales procesados, ofrecen servicios, desempeñan funciones de administración pública.

¿Qué no son las normas ISO?

• No son Especificaciones de Calidad de Productos.
• No son obligatorias.
• No es un programa de corta duración.
• No es el punto final de la mejora continua

El modelo de un sistema de gestión de la calidad basado en procesos que se muestra a continuación ha servido a las organizaciones para enfocar sus esfuerzos en aquellos procesos que aportan valor al cliente y garantizan la satisfacción de sus necesidades declaradas e implícitas:

  Para ver el gráfico seleccione la opción "Descargar" del menú superior

 El proceso de Responsabilidad de la Dirección se identifica con los procesos estratégicos que aportan directivas al resto de los procesos, tales como la definición de políticas, objetivos, responsabilidad y autoridad, comunicación, así como el compromiso de la dirección y la revisión del sistema por parte de ésta.

La gestión de recursos se refiere a la infraestructura y los recursos humanos, materiales y financieros que se identifica con los procesos de apoyo que soportan los procesos de realización, donde se manifiesta la cadena de valor que transforma las necesidades y expectativas de los clientes en productos que satisfagan sus expectativas.

Luego la medición, análisis y mejora permitirá determinar la eficacia, eficiencia y efectividad del resto de los proceso, y aportará la información necesaria para la toma de decisiones y la mejora continua del producto, los procesos y el sistema.

Es importante no ver estos procesos en orden cronológico ni como correspondientes a diferentes partes de la estructura de la organización, sino que son procesos simultáneos, íntimamente relacionados y extensivos a toda la organización.

2. Estrategia para la aplicación de la ISO 9000:2000 aplicada a PYMES de Software.

Es común que las empresas que acometen la implantación de sistemas de calidad ISO 9000 se enfrenten a las siguientes situaciones:

1. Se contratan consultores externos que aunque conozcan la calidad a nivel gerencial desconocen las especificidades de los procesos de software. Esto dificulta la adaptación eficaz de la norma a la organización y afecta la eficiencia del proceso de implantación.
2. El exceso de documentación provoca un rechazo general a la aplicación de la norma.
3. Se pretende comenzar la implantación de arriba hacia abajo, de modo que transcurre mucho tiempo en llegar al proceso concreto de realización del producto. Esto hace que no se vean resultados a corto plazo.
4. Se da más importancia a las cuestiones organizativas de la administración que a las del propio proyecto.
5. No se consideran las especificidades del proceso productivo como proceso de conocimiento: difícil estandarización, intervención del cliente prácticamente durante todo el proceso, mayor importancia del servicio posventa.

Para acometer la gestión de la calidad con resultados intermedios que permitan a la empresa ir obteniendo madurez en la medida en que avanza la implantación de las normas, se propone definir 5 niveles, ya no específicos al proceso de desarrollo del producto como da cuenta el CMM, sino referentes a la gestión de la calidad a nivel de toda la organización:

1. Nivel inicial
2. Nivel de proyecto.
3. Nivel de gestión total de calidad
4. Nivel de certificación
5. Nivel de referencia

Nivel inicial

Toda empresa de software aplica al menos un mínimo control de la calidad de sus productos y establece algunos parámetros mínimos como requisitos del producto.

Las empresas que trabajan a este nivel se caracterizan por:

1. Definición de políticas elementales de contratación.
2. Obtención de las especificaciones de los clientes.
3. Formación empírica de equipos de trabajo de acuerdo a la disponibilidad de personal que se tenga.
4. Compromisos de plazos de entrega sin criterios bien fundamentados.
5. Uso de herramientas de ingeniaría de software a voluntad de los desarrolladores.
6. Empleo de los lenguajes de programación en que se tiene experiencia, al no ser que el cliente exija lo contrario.
7. Mínima documentación.
8. Acta de aceptación del cliente quien generalmente no está en condiciones de evaluar adecuadamente el producto.
9. Deficiente organización del mantenimiento posventa del producto.

Nivel de proyecto

En este nivel se incluyen: evaluaciones, revisiones y auditorias, normas, procedimientos de control y seguimiento de errores, así como el registro de la información como vía de retroalimentación para la calidad del proyecto. Algunas acciones importantes que no pueden dejar de realizarse son: asegurar que los procesos de ingeniería de software sean usados durante todo el ciclo de vida del proyecto; evaluar mediante métricas, los requerimientos de calidad de los productos; chequear mediante métricas las condiciones anormales en los procesos y eliminarlas antes de terminar el producto; analizar las pérdidas de calidad para definir acciones para el mejoramiento continuo del proceso de desarrollo de software.

El siguiente modelo de Pressman (1998) muestra fehacientemente como asegurar a nivel de proyecto la calidad de proceso de desarrollo de software:

   Para ver el gráfico seleccione la opción "Descargar" del menú superior

Es necesario partir de un pequeño número de actividades del marco de trabajo que son aplicables a todos los proyectos de software, con independencia de su tamaño y complejidad. Un conjunto de tareas que permiten que las actividades del marco de trabajo se adapten a las características del proceso de software y a los requisitos del equipo de proyecto. Finalmente las actividades de protección tales como la gestión de la calidad del software, gestión de configuración del software y la medición. Estas actividades serán independientes del cualquier actividad del marco de trabajo y deben aparecer durante todo el proceso.

A este nivel pudiera organizarse la actividad de la forma siguiente:

1. Establecer políticas y procedimientos generales para: negociación del proyecto, decisión de plazos de entrega, formación del equipo de proyecto, decisión de plataformas de trabajo y lenguajes de programación, documentación mínima necesaria, herramientas comunes e imagen corporativa implícita en el software a desarrollar.
2. Planificar y organizar las tareas a ejecutar, definiendo las métricas del proyecto, los hitos, las pruebas a realizar en cada uno.
3. Ejecución del proyecto.
4. Control de calidad en cada uno de los hitos definidos y al final. (el control incluye la verificación y corrección).

1. Se definirán políticas en aquellos aspectos donde se requiera un alto nivel de flexibilidad como la negociación del proyecto y la decisión de plataformas de trabajo y lenguajes de programación.

   Pudiera definirse por ejemplo política de precios, requisitos de los contratos y todo lo que se relacione con el contacto directo con el cliente, de modo que no se establezcan camisas de fuerza que atenten finalmente contra su satisfacción con el servicio que se le ofrece.

   Se definirán procedimientos en aquellos aspectos donde sea posible regular cada uno de los pasos a dar y las alternativas posibles a evaluar.

   Para la definición de plazos de entrega pudiera trabajarse con rutas críticas o con las herramientas del Microsoft Project, por ejemplo. Para la formación del equipo de proyecto sería necesario establecer un procedimiento que permita establecer las competencias que requiere el proyecto de sus especialistas, la evaluación de esas competencias en el personal del que se pueda disponer y las métricas de medición de la inteligencia emocional del equipo. Los documentos mínimos pueden establecerse sobre la base de depurar las metodologías de análisis de sistema conocidas y definir lo que la organización considera necesario y con qué estructura. La imagen corporativa implícita en el software debe establecerse como criterio inicial que facilite los diseños de las diferentes interfaces. Las herramientas serán definidas con el objetivo de lograr una estandarización a nivel de la organización.

   Para desarrollar este marco de trabajo pueden crearse grupos de especialistas donde la experiencia cuente en primer lugar y obtenerse las políticas y procedimientos a partir de sesiones de trabajo. El Consejo Técnico Asesor de la Gerencia puede ser una vía propicia.

2. Políticas y procedimientos generales.

   Se definirán cada una de las tareas del proyecto, se asignarán responsables, participantes, plazos y formas de control. Las formas de control se determinan a partir de definir las métricas en cada etapa.

   Es importante que los controles se realicen en los hitos previamente definidos de manera que no se entorpezca el desarrollo del proyecto.

   Los períodos de control y corrección deben preverse en el cronograma de desarrollo del proyecto.

3. Planificación y organización de las tareas.
4. Ejecución del proyecto.

Además de cumplir con las políticas y procedimientos trazados así como con la planificación realizada, es importante tener en cuenta dos aspectos: la ingeniería del software y la documentación.

La ingeniería del software establece los requerimientos tecnológicos del diseño. Debe lograrse en la organización que todos sus especialistas dominen las técnicas y herramientas necesarias.

Teniendo en cuenta las diferencias profesionales y de experiencia de los especialistas, es importante realizar acciones de gestión del conocimiento y seguir, al menos, los principios básicos que garanticen la continua conversión del conocimiento tácito en explícito y viceversa.

Par ese fin se recomiendan algunas acciones de fácil implementación:

• Integrar los equipos con personal de diferente nivel de experiencia de modo que se trasmitan los conocimientos por la mejor vía posible que es la práctica.
• Formar equipos multidisciplinarios en relación con el proyecto, de manera que se compartan conocimientos de acuerdo al know how no informático que se requiere.
• Estimular por diferentes vías la compartición de los conocimientos, el desarrollo de clases y objetos para uso común y conformar una biblioteca compartida.
• Discusiones en equipo de las soluciones informáticas complejas y su explicitación por escrito, de modo que no se requiera reinventar la rueda.
• Formación inicial de los especialistas de reciente incorporación con políticas, procedimientos, soluciones técnicas documentadas.
• Formación del cliente y empatía de modo que se incorpore como un miembro del equipo, en posición constructiva y proactiva.

Un aspecto vital tanto para la calidad del proyecto como para ir sentando una cultura con vistas a la futura implantación de sistemas de calidad a nivel organizacional, es la documentación de cada una de las etapas en paralelo al desarrollo, de forma que se eviten omisiones o que la documentación sea una carga a realizar una vez terminado el software.

Es necesario insistir en que a este nivel debe establecerse la documentación mínima necesaria que garantice la trazabilidad del proceso de desarrollo y que deje constancia, sobre todo, de todos los contactos con el cliente. Debe tenerse presente que en esta industria, a diferencia de la mayoría, la interacción con el cliente se da a todo lo largo del proceso.

2. Control de calidad.

El control de calidad en cada uno de los hitos debe realizarse por personal especialmente dedicado a esta función. Debe escogerse los técnicos de mayor experiencia.

El control de calidad al final se recomienda lo realicen círculos de calidad creados ad hoc para cada proyecto.

La separación de las actividades de análisis, programación e implantación es de gran ayuda al permitir lograr de forma natural una contrapartida permanente que sirva de retroalimentación durante todo el proceso de desarrollo. Sin mencionar otros beneficios como el incremento de los niveles de productividad.

Nivel de gestión total de calidad.

Una vez superada la etapa de lograr la calidad en los proyectos, la empresa estará en condiciones de revisar las normas ISO 9000 de manera detallada y comenzar a adecuar sus actividades y procesos a los requisitos mínimos que ellas establecen.

Aquí es importante tener en cuenta:

1. Como la norma admite que la documentación puede estar en cualquier formato o tipo de medio, revisar los diseños de la intranet y de los sistemas de información digital que minimicen la burocracia del exceso de documentación con el que generalmente se acompaña la implantación de estas normas.
2. Dentro de la gestión de recursos, prestar la máxima atención a la gestión del capital humano (gestión del conocimiento a nivel de toda la organización y control de indicadores de capital intelectual).
3. Revisar el proceso de materialización del producto que se definió a nivel de proyecto a la luz de la norma.
4. Conceder especial importancia dentro de la revisión de requisitos relacionados con el producto a los no explícitos por parte del cliente y a los de ingeniería de software.
5. El control de cambios de diseño y desarrollo mediante los registros adecuados garantizará la calidad del proceso de mantenimiento del software.
6. La identificación y trazabilidad que establece la norma se garantizará con una adecuada gestión de la configuración.
7. La propiedad del cliente requiere un respeto riguroso: habrá que precisar la confidencialidad de la información que se maneja y hasta donde llega la participación del cliente en el know how no informático del producto.
8. En la preservación de producto orientarse especifican mete al control de versiones.
9. La medición, análisis y mejora se da en dos etapas: durante el desarrollo del software utilizando las métricas que proporcionan los múltiples modelos existentes y el seguimiento y medición posterior.
10. Se requiere implementar adecuados sistemas de satisfacción del cliente que permita retroalimentarse con el desempeño posterior del producto. Debe tenerse en cuenta que estos productos demuestran su eficacia sobre todo en momentos posteriores a su implementación cuando se requieren cambios de su configuración o cuando el volumen de datos procesados se hace significativamente grande.
11. Es importante implementar que la liberación del producto la realice personal distinto al encargado de su desarrollo.

Nivel de certificación.

Por la gran variabilidad de los procesos de desarrollo de software, es importante buscar una estabilidad del nivel anterior antes de pasar a este nivel.

Por otro lado, los procesos de desarrollo de software ocurren en plazos mucho mayores que los procesos productivos y de servicios convencionales, de ahí que para demostrar resultados con vistas a la certificación hay que esperar un tiempo mayor.

Una vez certificada la entidad tendrá que ser capaz en el tiempo de demostrar su aptitud para mantener la certificación otorgada en las auditorias recurrentes que establecen las normas.

Nivel de referencia.

Existe una tendencia a considerar el proceso de desarrollo de software como un proceso de I + D lo que no se considera exacto. El verdadero proceso de investigación y desarrollo se da en el software cuando se trabaja en nuevas herramientas de ingeniería y en nuevos métodos de trabajo que permitan obtener resultados superiores.

Las empresas de alto desempeño se convierten en referencia para otras que comienzan a partir de convertir sus métodos y experiencias en estándares de trabajo.

Por otro lado, el desarrollo de software propicia la producción de herramientas de ingeniería y de codificación que hacen mas efectivos y productivos los procesos.

Conclusiones

1. Muchas empresas prestigiosas de software implementan sus propios modelos de calidad.
2. Para las pequeñas y medianas empresas de software la implantación de sistemas de la calidad basados en las normas ISO 9000 puede constituir el mejor camino a seguir pues estas normas definen los requisitos básicos de la organización y por otro lado la certificación le confiere un prestigio importante ante sus clientes.
3. La solución ideal para empresas principiantes es integrar en la ISO 9000 todas aquellas características propias del producto de software que se contemplan en las otras metodologías.
4. La implantación de sistemas de calidad ISO 9000 en empresas de software debe hacerse por niveles de desarrollo.
5. El nivel de proyecto constituye el núcleo de la gestión de calidad en empresas de software ya que cada proyecto es a su vez una empresa.
6. La inclusión de la gestión del conocimiento dentro del sistema de calidad es un requisito básico para las empresas de software.

Bibliografía.

Basili, V.R. y Rombach, H.D., "The TAME Project: Towards Improvement-Oriented Software Environments", IEEE Transaction on Software Engineering,14(6), 758-73 1988.

Boehm, B.W., Kaspar, J.R. y otros "Characteristics of Software Quality", TRW Series of Software Technology, 1978.

Boehm, B.W., Clark, B., Horowitz, E. et al., "Cost Models for future life cycle processes: COCOMO 2.0", Annals of Software Engineering 1(1), pp 1-24, 1995.

DeMarco, T., "Controlling Software Projects", Yourdon Press, 1982.

Dolado, J.J. y Fernández, L. (coordinadores). "Medición para la Gestión en la Ingeniería del Software". Ra-ma, 2000.

Farbey, B., "Software Quality metrics: considerations about requirements and requirements specification", Information and Software Technology, 32 (1), pp 60-64, 1990.

Fernández, Luis y Miren Idoia Alarcón. Necesidades de medición en la gestión y aseguramiento de calidad del software. [en línea: 05/04/04] http://www.sc.ehu.es/jiwdocoj/remis/docs/aseguracal.htm

Gilb, T. "Principles of Software Engineering Management", Addison-Wesley, 1988.

ISO/IEC "Information Technology – Information Resources Dictionary System (IRDS) – Framework", ISO/IEC intl. Standard edition, 1990.

ISO/IEC 9126, "Software Product Evaluation – Quality Characteristics and Guidelines for their Use ", 1991.

Lorenz, M. and Kidd, J., "Object_oriented Software Metrics", Prentice Hall 1994.

McCall, J.A., Richards, P.K. and Walters, G.F. "Factors in Software Quality", RADC TR-77-369, US Rome Air Development Center Reports NTIS AD/A-049 014, 015, 055, 1977.

Paulk, M., Curtis, B., Chrissis, M., and Weber, C. "Capability Maturity Model for Software: Version 1.1". Technical Report SEI-93-TR-24, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania, USA, 1993.

Pressman, Roger S. (1998) Ingeniería de software. Un enfoque práctico. Cuarta Edición, Madrid, Mc Graw-Hill Interamericana de España S.A.

Rout, T.P. "Software Process Improvement and Practice", 1(1), pp 57-66, 1995.

Samson, W.B., Nevill, D.G. Y Dugard, P.I., "Predictive software Metrics based on a Formal Specification", Software Engineering Journal, 5(1), 1990.

SPICE, "SPICE Document Suite, Software Process Improvement and Capability determination", , 1999.

Tinnirello, Paul C.,How's Your IT: Teetering Or Leading-Edge PC Week May 11, v15 n19 p77, 1998

M.Sc. Abilio Marrero Rodríguez