Pages Menu
Categories Menu

Posted by on Oct 24, 2012 in General | 7 comments

Cómo estandarizar la evaluación de la calidad del producto software… la ISO 9126 y la ISO 25000 (1/2)

Todos deseamos que después de un desarrollo el producto software sea “de calidad”… ¿Pero qué es calidad? Para algunos “que funcione bien”, para otros “que sea fiable”, o “que esté bien construido”, “que pase las pruebas”, etc. Así podríamos encontrar decenas de definiciones que pueden asociarse a “calidad software”, muchas diferentes, otras similares, cada uno con la suya.

Sin un criterio unificado, por ejemplo, aceptar un proyecto en cuyo contrato dice que el software a desarrollar será “de calidad” sería un suicidio… ¿qué entenderá el cliente por calidad? ¿Será lo mismo qué entiende el desarrollador? ¿Con qué criterios de calidad puedo aceptar una entrega software?

Para evitar estos problemas, fijar una terminología, y saber concretamente de qué calidad estamos hablando cada uno, desde hace ya sus años se han ido creando modelos de “calidad del producto software”. Y aunque estos son menos populares que los de los procesos (CMMI, etc.) son cada vez más importantes, e imprescindibles a la hora de evaluar la calidad del software.

Y este no es un tema nuevo. En 1977 McCall creó un árbol de factores que afectan a la calidad del producto software (no al proceso, ni a las metodologías, ni al equipo… sólo al producto). Sus factores de calidad tenían que ver con la operación, revisión y transición de los productos software. Y en 1978 el famoso Boehm publicó un modelo similar, diferente del modelo de McCall, y que agregaba el rendimiento y la “utilidad” del producto.

Pero no fue hasta 1991, cuando fue publicada la norma ISO 9126, que unifica criterios de los modelos anteriores, cuando los modelos de calidad del producto software empiezan realmente a ser una herramienta para las empresas.

La ISO 9126, al igual que los modelos de McCall y Boehm, propone una jerarquía de atributos de calidad. Hoy esta mítica norma tiene una sucesora, la serie de normas ISO 25000.

En esta serie de dos artículos vamos a revisar, y sintetizar las normas ISO 9126 e ISO 25000. Comencemos…

La norma ISO 9126 y la ISO 25000

El norma ISO 9126, ahora bajo el proyecto SQuaRE (Software Product Quality Requeriments and Evaluation) en que desarrolla la norma ISO 25000, establece un modelo de calidad basado en modelos de calidad propuestos por los investigadores durante los últimos 30 años.

La ISO 9126, y su sucesora, la ISO 25000, propone un modelo de calidad que se divide en tres aproximaciones: interna (calidad del código), externa (calidad en la ejecución) y en uso. En este caso, el modelo establece diez características, seis de ellas comunes a las vistas interna y externa y las otras cuatro propias de la vista en uso.

Quizás las más populares y usadas son las características que definen las vistas interna y externa, y que son:

– Funcionalidad, capacidad del software de proveer los servicios necesarios para cumplir con los requisitos funcionales.

– Fiabilidad, capacidad del software de mantener las prestaciones requeridas del sistema, durante un tiempo establecido y bajo un conjunto de condiciones definidas.

– Eficiencia, relación entre las prestaciones del software y los requisitos necesarios para su utilización.

– Usabilidad, esfuerzo requerido por el usuario para utilizar el producto satisfactoriamente.

– Mantenibilidad, esfuerzo necesario para adaptarse a las nuevas especificaciones y requisitos del software.

– Portabilidad, capacidad del software para ser transferido de un entorno a otro.

Es decir, que según lo anterior, la calidad software se puede ver desde 6 puntos de vista.

A su vez, de manera jerárquica, cada uno de los anteriores se divide en subcaracterísticas de menor nivel. Veamos esto con un ejemplo, el de la característica más usada: la mantenibilidad.

La mantenibilidad en ISO 9126 / ISO 25000

La mantenibilidad es una de las características más importantes de la calidad de un producto software, quizá sea la parte más famosa de la norma ISO 9126 / ISO 25000. Atributo intrínsecamente asociado con el proceso de mantenimiento, y que representa la mayor parte de los costes en el Ciclo de Vida Software. Según el modelo de calidad recogido por la norma ISO 9126 / ISO 25000 está formada por las siguientes subcaracterísticas:

– Analizabilidad, facilidad para analizar el software en busca de deficiencias e identificar sus componentes y artefactos.

– Cambiabilidad, capacidad de permitir modificaciones en el producto software.

– Estabilidad, capacidad de evitar efectos inesperados tras la realización de modificaciones en el software.

– Capacidad de ser probado, capacidad para validar los cambios en el software.

– Adherencia a las normas, cumplimiento de los estándares y convenciones de mantenibilidad. Hace referencia a todas las anteriores.

Aquí tienes el enlace a la parte II de este post.

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.
Javier Garzás

7 Comments

  1. Interesante tema..

    Un comentario:
    En la definicion de la caracteristica de
    “Eficiencia, relación entre las prestaciones del software y los requisitos necesarios para su utilización”
    Yo creo que resula más acertado en lugar de “requisitos” decir “…recursos necesarios para su funcionamiento”.

  2. Coincido que es un tema interesante.

    La calidad es un tema amplio, subjetivo y difícil de ser capturado por una norma.
    Sin embargo éstas pueden mostrar un camino para definir al menos algunos aspectos de ella, fundamentalmente los relacionados con las propiedades que el producto debe poseer para exhibir luego caracteristicas que el usuario aprecia como de valor. Será trabajo luego del arquitecto componer el producto de modo tal estas caracteristicas esten incorporadas.
    Dado que como menciona Carme existen factores no técnicos que el usuario valora, el mejor producto sin estos factores adicionales no será visto como de calidad.
    Esto a mi juicio plantea varias preguntas:
    ¿Cómo realizamos este análisis y descubrimiento?
    ¿Quién lo realiza?
    ¿Cómo informamos al arquitecto qué debe incorporar en su análisis?
    ¿Quién es finalmente el responsable de garantizar que esa calidad esperada (técnica + el resto) se concrete?

    … y podríamos seguir.

    Cada uno tendrá su opinión, yo tengo la mía, sobre lo antes mencionado pero no hay duda que es un tema abierto y que trasciende la visión técnica de la arquitectura o la enunciativa del negocio.

    Saludos,
    Raúl

  3. Hola Javier, disculpa una pregunta, ¿en la norma o algún documento podremos encontrar métricas asociadas a esas características? ya que si bien entendemos qué significa la característica, sería de mucha ayuda saber que grado de cumplimiento o desempeño estamos a fin de mejorar o poder compararnos con la industria.

    Saludos.

  4. La norma ISO 9126 incluye tablas de ejemplos para métricas de calidad interna, externa y en uso, para cada subcaracaterística del modelo de Calidad que plantea.
    Eso sí, son algo teóricas…

  5. Javier,
    Las areas que se dedican a validar el software son conocida como, pruebas, testing, certificacion de software, se puede decir que cuando aplicamos pruebas funcionales estamos validando el atributo de calidad de funcionalidad, para el caso de los otros atributos de calidad como se hace la verificacion?.

    Saludos
    Julio

    • Hola,

      Las pruebas son una manera de validad, auqnue hay más. Verificar está más relacionado con el cumplimiento de las normas internas.

      Saludos

Trackbacks/Pingbacks

  1. Bitacoras.com - Información Bitacoras.com... Valora en Bitacoras.com: Todos deseamos que después de un desarrollo el producto software sea “de calidad”… ¿Pero…

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This