Uno de los problemas que se afrontan actualmente en la esfera de la computación es la calidad del software. Desde la década del 70, este tema ha sido motivo de preocupación para especialistas, ingenieros, investigadores y comercializadores de software, los cuales han realizado gran cantidad de investigaciones al respecto con dos objetivos fundamentales:
1. ¿Cómo obtener un software con calidad?
2. ¿Cómo evaluar la calidad del software?
Ambas interrogantes conllevan amplias respuestas, pero están estrechamente ligadas al concepto de la calidad del software, que es el resultado de la primera y la fuente de la segunda.
CALIDAD DEL SOFTWARE
La calidad del software es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y existencia. La calidad es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e integridad.
La calidad del software es medible y varía de un sistema a otro o de un programa a otro. Un software elaborado para el control de naves espaciales debe ser confiable al nivel de "cero fallas"; un software hecho para ejecutarse una sola vez no requiere el mismo nivel de calidad; mientras que un producto de software para ser explotado durante un largo período (10 años o más), necesita ser confiable, mantenible y flexible para disminuir los costos de mantenimiento y perfeccionamiento durante el tiempo de explotación.
La calidad del software puede medirse después de elaborado el producto. Pero esto puede resultar muy costoso si se detectan problemas deriva dos de imperfecciones en el diseño, por lo que es imprescindible tener en cuenta tanto la obtención de la calidad como su control durante todas las etapas del ciclo de vida del software.
SOFTWARE DE CALIDAD
La obtención de un software con calidad implica la utilización de metodologías o procedimientos estándar para el análisis, diseño, programación y prueba del software que permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software.
La política establecida debe estar sustentada sobre tres principios básicos: tecnológico, administrativo y ergonómico.
1. El principio tecnológico define las técnicas a utilizar en el proceso de desarrollo del software.
2. El principio administrativo contempla las funciones de planificación y control del desarrollo del software, así como la organización del ambiente o centro de ingeniería de software.
3. El principio ergonómico define la interfaz entre el usuario y el ambiente automatizado.
La adopción de una buena política contribuye en gran medida a lograr la calidad del software, pero no la asegura. Para el aseguramiento de la calidad es necesario su control o evaluación.
CONTROL DE CALIDAD DEL SOFTWARE
Para controlar la calidad del software es necesario, ante todo, definir los parámetros, indicadores o criterios de medición, ya que, como bien plantea Tom De Marco, "usted no puede controlar lo que no se puede medir".
Las cualidades para medir la calidad del software son definidas por innumerables autores, los cuales las denominan y agrupan de formas diferentes. Por ejemplo, John Wiley define métricas de calidad y criterios, donde cada métrica se obtiene a partir de combinaciones de los diferentes criterios. La Metodología para la evaluación de la calidad de los medios de programas de la CIC, de Rusia, define indicadores de calidad estructurados en cuatro niveles jerárquicos: factor, criterio, métrica, elemento de evaluación, donde cada nivel inferior contiene los indicadores que conforman el nivel precedente. Otros autores identifican la calidad con el nivel de complejidad del software y definen dos categorías de métricas: de complejidad de programa o código, y de complejidad de sistema o estructura.
Todos los autores coinciden en que el software posee determinados índices medibles que son las bases para la calidad, el control y el perfeccionamiento de la productividad.
Una vez seleccionados los índices de calidad, se debe establecer el proceso de control, que requiere los siguientes pasos:
1. Definir el software que va a ser controlado: clasificación por tipo, esfera de aplicación, complejidad, etc., de acuerdo con los estándares establecidos para el desarrollo del software.
2. Seleccionar una medida que pueda ser aplicada al objeto de control. Para cada clase de software es necesario definir los indicadores y sus magnitudes.
3. Crear o determinar los métodos de valoración de los indicadores: métodos manuales como cuestionarios o encuestas estándares para la medición de criterios periciales y herramientas automatizadas para medir los criterios de cálculo.
4. Definir las regulaciones organizativas para realizar el control: quiénes participan en el control de la calidad, cuándo se realiza, qué documentos deben ser revisados y elaborados, etc.
A partir del análisis de todo lo anterior, nuestro Centro se encuentra enfrascado en un proyecto para el Aseguramiento de la Calidad del Software (ACS), válido para cualquier entidad que se dedique a la investigación, producción y comercialización del software, el cual incluye la elaboración de un Sistema de Indicadores de la Calidad del Software, la confección de una Metodología para el Aseguramiento de la Calidad del Software y el desarrollo de herramientas manuales y automatizadas de apoyo para la aplicación de las técnicas y procedimientos del ACS, de forma tal que se conforme un Sistema de Aseguramiento de la Calidad del Software.
ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE
Desde el punto de vista de la evidencia, la IEEE define el aseguramiento de la calidad como “Una guía planificada y sistemática de todas las acciones necesarias para proveer la evidencia adecuada de que un producto cumple los requerimientos técnicos establecidos. Un conjunto de actividades diseñadas para evaluar el proceso por el cual un producto es desarrollado o construido.”
La función de aseguramiento de la calidad tiene como finalidad primaria el determinar si las necesidades de los usuarios están siendo satisfechas adecuadamente. Otra de sus funciones es la de determinar los costos que puede causar el añadir ciertas características al producto, ya que tarde o temprano, la economía resulta ser un factor decisivo para obtener un producto de calidad. Para determinar si las necesidades de los usuarios están siendo satisfechas, se deben de evaluar tres áreas:
1. Objetivos: Los objetivos de la organización son primero, luego vienen los requerimientos del usuario. Los objetivos de cualquier usuario deben de estar en armonía con los objetivos de la organización,
2. Métodos: Deben de utilizarse métodos que contengan u observen las políticas, procedimientos y estándares de la organización,
3. Ejecución: Optimización del uso de hardware y software al implementar los productos de software.
Para evaluar las áreas expuestas, es necesario que se cuente con un programa de aseguramiento de calidad que sea efectivo y que tenga un impacto dentro del desarrollo y prueba del producto de software final.
PRUEBA DEL SOFTWARE
La fase de pruebas es una de las más costosas del ciclo de vida software. En sentido estricto, deben realizarse pruebas de todos los artefactos generados durante la construcción de un producto, lo que incluye especificaciones de requisitos, casos de uso, diagramas de diversos tipos y, por supuesto, el código fuente y el resto de productos que forman parte de la aplicación (p.ej., la base de datos). Obviamente, se aplican diferentes técnicas de prueba a cada tipo de producto software.
Proceso de pruebas en el ciclo de vida
El estándar ISO/IEC 12207 (ISO/IEC 1995) identifica tres grupos de procesos en el ciclo de vida del software:
· Procesos principales, grupo en el que incluye los procesos de Adquisición, Suministro, Desarrollo, Operación y Mantenimiento.
· Procesos de la organización, en donde se encuentran los procesos de Gestión, Mejora, Infraestructura y Formación.
· Procesos de soporte o auxiliares, en donde están los procesos de Documentación, Gestión de la Configuración, Auditoría, Resolución de Problemas, Revisión Conjunta, Aseguramiento de la Calidad, Verificación, Validación,
No define, como se observa, un proceso de pruebas como tal, sino que aconseja, durante la ejecución de los procesos principales o de la organización, utilizar los procesos de soporte. Entre éstos se encuentran los procesos de Validación y de Verificación:
· El proceso de Validación tiene como objetivo determinar si los requisitos y el sistema final cumplen los objetivos para los que se construyó el producto, respondiendo así a la pregunta ¿el producto es correcto?
· El proceso de Verificación intenta determinar si los productos software de una actividad se ajustan a los requisitos o a las condiciones impuestas en actividades anteriores. De este modo, la pregunta a la que responde este proceso es ¿se está construyendo el producto correctamente?
Del proceso de Verificación se observa la importancia de verificar cada uno de los productos que se van construyendo, bajo la asunción de que si lo que se va construyendo es todo ello correcto, también lo será el producto final. Igualmente, se observa que el proceso de Validación resalta la importancia de comprobar el cumplimiento de los objetivos de los requisitos y del sistema final, de suerte que podría construirse un Plan de pruebas de aceptación desde el momento mismo de tener los requisitos, que sería comprobado al finalizar el proyecto. Si tras la fase de requisitos viniese una segunda de diseño a alto nivel del sistema, también podría prepararse un Plan de pruebas de integración, que sería comprobado tras tener codificados los diferentes módulos del sistema. Esta correspondencia entre fases del desarrollo y tipos de pruebas produce el llamado “modelo en V”.
Pruebas de requisitos
La prueba de requisitos pretende comprobar los tres principales atributos de calidad de los requisitos, con el fin de detectar tantos errores como sea posible y cuanto antes: corrección (carencia de ambigüedad), compleción (especificación completa y clara del problema) y consistencia (que no haya requisitos contradictorios).
Pruebas del diseño
La fase de diseño tiene como objetivo generar un conjunto de especificaciones completas del sistema que se va a implementar, transformando los requisitos en un Plan de implementación.
La prueba del diseño debe comprobar su consistencia, compleción, corrección, factibilidad (es decir, que el diseño sea realizable) y trazabilidad (es decir, que se pueda “navegar” desde un requisito hasta el fragmento del diseño en que éste se encuentra).
Revisiones e inspecciones del código fuente
Las revisiones e inspecciones de código fuente son una técnica para la detección manual de errores en el código. Se trabaja bajo el principio de que “cuatro ojos ven más que dos”, de tal manera que el método de trabajo consistirá, básicamente, en pasar el código escrito por un programador a un tercero o grupo de terceros, que tratará de encontrar posibles errores, faltas de adecuación al estilo de codificación utilizado por la organización, etc. Para ello suelen utilizarse listas de comprobación (checklists), que enumeran defectos y en los que el revisor anota su presencia o ausencia.
1. ¿Cómo obtener un software con calidad?
2. ¿Cómo evaluar la calidad del software?
Ambas interrogantes conllevan amplias respuestas, pero están estrechamente ligadas al concepto de la calidad del software, que es el resultado de la primera y la fuente de la segunda.
CALIDAD DEL SOFTWARE
La calidad del software es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y existencia. La calidad es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e integridad.
La calidad del software es medible y varía de un sistema a otro o de un programa a otro. Un software elaborado para el control de naves espaciales debe ser confiable al nivel de "cero fallas"; un software hecho para ejecutarse una sola vez no requiere el mismo nivel de calidad; mientras que un producto de software para ser explotado durante un largo período (10 años o más), necesita ser confiable, mantenible y flexible para disminuir los costos de mantenimiento y perfeccionamiento durante el tiempo de explotación.
La calidad del software puede medirse después de elaborado el producto. Pero esto puede resultar muy costoso si se detectan problemas deriva dos de imperfecciones en el diseño, por lo que es imprescindible tener en cuenta tanto la obtención de la calidad como su control durante todas las etapas del ciclo de vida del software.
SOFTWARE DE CALIDAD
La obtención de un software con calidad implica la utilización de metodologías o procedimientos estándar para el análisis, diseño, programación y prueba del software que permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software.
La política establecida debe estar sustentada sobre tres principios básicos: tecnológico, administrativo y ergonómico.
1. El principio tecnológico define las técnicas a utilizar en el proceso de desarrollo del software.
2. El principio administrativo contempla las funciones de planificación y control del desarrollo del software, así como la organización del ambiente o centro de ingeniería de software.
3. El principio ergonómico define la interfaz entre el usuario y el ambiente automatizado.
La adopción de una buena política contribuye en gran medida a lograr la calidad del software, pero no la asegura. Para el aseguramiento de la calidad es necesario su control o evaluación.
CONTROL DE CALIDAD DEL SOFTWARE
Para controlar la calidad del software es necesario, ante todo, definir los parámetros, indicadores o criterios de medición, ya que, como bien plantea Tom De Marco, "usted no puede controlar lo que no se puede medir".
Las cualidades para medir la calidad del software son definidas por innumerables autores, los cuales las denominan y agrupan de formas diferentes. Por ejemplo, John Wiley define métricas de calidad y criterios, donde cada métrica se obtiene a partir de combinaciones de los diferentes criterios. La Metodología para la evaluación de la calidad de los medios de programas de la CIC, de Rusia, define indicadores de calidad estructurados en cuatro niveles jerárquicos: factor, criterio, métrica, elemento de evaluación, donde cada nivel inferior contiene los indicadores que conforman el nivel precedente. Otros autores identifican la calidad con el nivel de complejidad del software y definen dos categorías de métricas: de complejidad de programa o código, y de complejidad de sistema o estructura.
Todos los autores coinciden en que el software posee determinados índices medibles que son las bases para la calidad, el control y el perfeccionamiento de la productividad.
Una vez seleccionados los índices de calidad, se debe establecer el proceso de control, que requiere los siguientes pasos:
1. Definir el software que va a ser controlado: clasificación por tipo, esfera de aplicación, complejidad, etc., de acuerdo con los estándares establecidos para el desarrollo del software.
2. Seleccionar una medida que pueda ser aplicada al objeto de control. Para cada clase de software es necesario definir los indicadores y sus magnitudes.
3. Crear o determinar los métodos de valoración de los indicadores: métodos manuales como cuestionarios o encuestas estándares para la medición de criterios periciales y herramientas automatizadas para medir los criterios de cálculo.
4. Definir las regulaciones organizativas para realizar el control: quiénes participan en el control de la calidad, cuándo se realiza, qué documentos deben ser revisados y elaborados, etc.
A partir del análisis de todo lo anterior, nuestro Centro se encuentra enfrascado en un proyecto para el Aseguramiento de la Calidad del Software (ACS), válido para cualquier entidad que se dedique a la investigación, producción y comercialización del software, el cual incluye la elaboración de un Sistema de Indicadores de la Calidad del Software, la confección de una Metodología para el Aseguramiento de la Calidad del Software y el desarrollo de herramientas manuales y automatizadas de apoyo para la aplicación de las técnicas y procedimientos del ACS, de forma tal que se conforme un Sistema de Aseguramiento de la Calidad del Software.
ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE
Desde el punto de vista de la evidencia, la IEEE define el aseguramiento de la calidad como “Una guía planificada y sistemática de todas las acciones necesarias para proveer la evidencia adecuada de que un producto cumple los requerimientos técnicos establecidos. Un conjunto de actividades diseñadas para evaluar el proceso por el cual un producto es desarrollado o construido.”
La función de aseguramiento de la calidad tiene como finalidad primaria el determinar si las necesidades de los usuarios están siendo satisfechas adecuadamente. Otra de sus funciones es la de determinar los costos que puede causar el añadir ciertas características al producto, ya que tarde o temprano, la economía resulta ser un factor decisivo para obtener un producto de calidad. Para determinar si las necesidades de los usuarios están siendo satisfechas, se deben de evaluar tres áreas:
1. Objetivos: Los objetivos de la organización son primero, luego vienen los requerimientos del usuario. Los objetivos de cualquier usuario deben de estar en armonía con los objetivos de la organización,
2. Métodos: Deben de utilizarse métodos que contengan u observen las políticas, procedimientos y estándares de la organización,
3. Ejecución: Optimización del uso de hardware y software al implementar los productos de software.
Para evaluar las áreas expuestas, es necesario que se cuente con un programa de aseguramiento de calidad que sea efectivo y que tenga un impacto dentro del desarrollo y prueba del producto de software final.
PRUEBA DEL SOFTWARE
La fase de pruebas es una de las más costosas del ciclo de vida software. En sentido estricto, deben realizarse pruebas de todos los artefactos generados durante la construcción de un producto, lo que incluye especificaciones de requisitos, casos de uso, diagramas de diversos tipos y, por supuesto, el código fuente y el resto de productos que forman parte de la aplicación (p.ej., la base de datos). Obviamente, se aplican diferentes técnicas de prueba a cada tipo de producto software.
Proceso de pruebas en el ciclo de vida
El estándar ISO/IEC 12207 (ISO/IEC 1995) identifica tres grupos de procesos en el ciclo de vida del software:
· Procesos principales, grupo en el que incluye los procesos de Adquisición, Suministro, Desarrollo, Operación y Mantenimiento.
· Procesos de la organización, en donde se encuentran los procesos de Gestión, Mejora, Infraestructura y Formación.
· Procesos de soporte o auxiliares, en donde están los procesos de Documentación, Gestión de la Configuración, Auditoría, Resolución de Problemas, Revisión Conjunta, Aseguramiento de la Calidad, Verificación, Validación,
No define, como se observa, un proceso de pruebas como tal, sino que aconseja, durante la ejecución de los procesos principales o de la organización, utilizar los procesos de soporte. Entre éstos se encuentran los procesos de Validación y de Verificación:
· El proceso de Validación tiene como objetivo determinar si los requisitos y el sistema final cumplen los objetivos para los que se construyó el producto, respondiendo así a la pregunta ¿el producto es correcto?
· El proceso de Verificación intenta determinar si los productos software de una actividad se ajustan a los requisitos o a las condiciones impuestas en actividades anteriores. De este modo, la pregunta a la que responde este proceso es ¿se está construyendo el producto correctamente?
Del proceso de Verificación se observa la importancia de verificar cada uno de los productos que se van construyendo, bajo la asunción de que si lo que se va construyendo es todo ello correcto, también lo será el producto final. Igualmente, se observa que el proceso de Validación resalta la importancia de comprobar el cumplimiento de los objetivos de los requisitos y del sistema final, de suerte que podría construirse un Plan de pruebas de aceptación desde el momento mismo de tener los requisitos, que sería comprobado al finalizar el proyecto. Si tras la fase de requisitos viniese una segunda de diseño a alto nivel del sistema, también podría prepararse un Plan de pruebas de integración, que sería comprobado tras tener codificados los diferentes módulos del sistema. Esta correspondencia entre fases del desarrollo y tipos de pruebas produce el llamado “modelo en V”.
Pruebas de requisitos
La prueba de requisitos pretende comprobar los tres principales atributos de calidad de los requisitos, con el fin de detectar tantos errores como sea posible y cuanto antes: corrección (carencia de ambigüedad), compleción (especificación completa y clara del problema) y consistencia (que no haya requisitos contradictorios).
Pruebas del diseño
La fase de diseño tiene como objetivo generar un conjunto de especificaciones completas del sistema que se va a implementar, transformando los requisitos en un Plan de implementación.
La prueba del diseño debe comprobar su consistencia, compleción, corrección, factibilidad (es decir, que el diseño sea realizable) y trazabilidad (es decir, que se pueda “navegar” desde un requisito hasta el fragmento del diseño en que éste se encuentra).
Revisiones e inspecciones del código fuente
Las revisiones e inspecciones de código fuente son una técnica para la detección manual de errores en el código. Se trabaja bajo el principio de que “cuatro ojos ven más que dos”, de tal manera que el método de trabajo consistirá, básicamente, en pasar el código escrito por un programador a un tercero o grupo de terceros, que tratará de encontrar posibles errores, faltas de adecuación al estilo de codificación utilizado por la organización, etc. Para ello suelen utilizarse listas de comprobación (checklists), que enumeran defectos y en los que el revisor anota su presencia o ausencia.
