Juan Carlos Granja Alvarez
Profesor Responsable del Grupo de Investigación de Lenguajes y Sistemas Informáticos e Ingeniería del Software de la Universidad de Granada
jcgranja@goliat.ugr.es
En la coordinación del monográfico de Ingeniería del Software, comentábamos al mencionar las llamadas "pastillas del software", el interés que en la evolución de la Ingeniería del Software ha existido siempre por la Calidad. Lejos queda ya el hecho histórico de la ciudad de Garmisch, donde en 1968 se acuñó el término de Ingeniería del Software y la respuesta dada a la llamada crisis del software de finales de los años sesenta.
Se ha evolucionado mucho en los enfoques de la calidad. A finales de los sesenta, cada vez que se quería afrontar la mejora del software todo se dirigía a la mejora del código dejando olvidado todo lo que le rodeaba. Ya en los años ochenta se comenzó a tener en cuenta los aspectos de especificaciones, diseño, evaluación y gestión del software. Pese a estos cambios, persiste la problemática ya que el nivel de complejidad del software va aumentando y no se alcanzan los niveles de calidad deseados.
Hablar de la Universidad de Carnegie Mellon, de su Instituto de Ingeniería del Software, nos trae a la memoria el año 1986. En este año el Departamento de Defensa de los EE.UU. encargó una guía para la selección de los contratistas del software. De aquí salió la creación de un método que permite valorar el proceso de software en función de un modelo de madurez de la capacidad, el Capability Maturity Model (C.M.M.). Surge así el recuerdo de Watts Humphrey y de sus importantes aportaciones. Para este autor la solución a los problemas de calidad del software consiste en una mejora de los procesos con los que la organización construye, mantiene y gestiona el software. El CMM establece cinco niveles de los que el Departamento de Defensa exige nivel tres a los contratistas. Este método ha sido el punto de partida de muchos modelos posteriores, como BOOTSTRAP, TRILLIUM y STD.
En Europa hay que resaltar la labor desarrollada por el European Software Institute. En este monográfico tenemos la oportunidad de contar con la aportación de su Director Técnico Hans-Jürgen Kugler, que nos da su visión de la mejora de los procesos de software.
La investigación en esta línea se ha impulsado mucho mediante proyectos Esprit, apoyados por Europa, como METKIT, PYRAMID, y otros que han aportado bases teóricas claras en este campo.
La International Organization for Standadization contituye el otro foco de aportaciones. En 1987 publicó toda la serie ISO 9000: 9001, 9002, 9003 que indican los elementos del sistema de calidad y la 9004 que aporta indicaciones y los elementos del sistema de calidad.
Una tercera vertiente de aportaciones importantes procede de Australia, pero no quisieramos extendernos en estos temas en esta presentación.
Una evolución la podemos apreciar a través de los Congresos de Calidad de Software, organizados por el Comité de Software de la European Organization for Quality (E.O.Q.). En el primero, celebrado en Bruselas en 1988, se centró en los elementos de control, tales como las pruebas y su método, herramientas y técnicas aplicables a las pruebas unitarias, de integración, de sistemas y de aceptación. En el celebrado en Oslo en 1990, las pruebas métricas de producto fueron el eje central. En 1992, en Madrid, se resaltó la reciente publicación de la directiva comunitaria relativa a la certificación según ISO 9001. En Basilea, 1994, se dejó sentir la etapa de transición del sistema ISO 9001 a los modelos de madurez y mejora continua. El pasado 1996 se celebró en Dublín y quizás habría que resaltar la consolidación de los modelos de mejora continua y la aportación de experiencias cada vez más frecuentes en la utilización de las tecnologías orientadas a los objetos. En este congreso se dedicó una sesión a este apartado.
En la actualidad hay que centrar la atención en la "mejora de los procesos" como forma de aumentar los niveles de calidad de los productos software. Se apuesta por la adopción de técnicas de gestión de la calidad y procedimientos de certificación de los sistemas de calidad. La profundización de la madurez de la Ingeniería del Software permite asegurar la calidad.
El monográfico de Novática dedicado a Calidad del Software (número 99, Septiembre-Octubre de 1992) había quedado en la historia de esta revista como la única monografía que habíamos realizado los autores que trabajábamos en esta linea a nivel nacional. Cuando en el número de Septiembre-Octubre de 1996 publicamos la petición de artículos para el presente número monográfico, no podíamos imaginar la masiva respuesta de los autores, que desde la industria y el mundo académico se interesaron al enviar sus experiencias en Calidad del Software. El óptimo nivel medio de los abun-dantes artículos recibidos llevó al Consejo Editorial de la revista a tomar la decisión de dividir su publicación en dos números monográficos, el actual y el 128, correspondiente a Julio-Agosto de 1997. Esta decisión ha sido comunicada a los autores afectados, que han comprendido la decisión.
Esta cantidad de aportaciones ha supuesto un mayor esfuerzo para el Comité de Revisión (formado por Antonio Amescua Seco, Julio González Sanz, Peter Hodgson Friedrichs, Gloria Nistal Rosique, Mario Piattini Velthius, J. Ángel Velázquez Iturbide y el editor/coordinador que escribe esta presentación). El contenido del monográfico no se ha querido someter a restricciones temáticas.
Es difícil aventurar tendencias futuras en un campo tan dinámico como éste, pero podemos tener en cuenta la evolu-ción en los últimos años. Terminando en Marzo de 1997 la segunda fase de prueba en empresas de desarrollo del proyecto SPICE, seguirá siendo un campo de investigación en el que profundizar. Por otra parte, dentro de los campos de investigación hay que hablar de las métricas relacionadas con los procesos, donde encontramos nuevos referentes.
Nos podemos despedir ya hasta el citado número 128 (Calidad del Software - II), esperando que este apasionante campo de investigación nos traiga nuevas tendencias por las que caminar y podamos potenciar nuestros procesos investigadores.
|
|
|