AVENUES FOR FURTHER STUDY

La palabra calidad tiene múltiples significados, por ejemplo, puede definirse como la percepción del cliente frente a un producto o servicio recibido. También puede considerarse como un conjunto de propiedades, inherentes a un objeto, que permiten apreciarlo como igual, mejor o peor que el resto de los objetos de su mismo tipo. El diccionario de la Real Academia Española [40] define calidad como “propiedad o conjunto de propiedades inherentes a algo, que permiten juzgar su valor”.

Baker y Fisher [34] presentan la definición de calidad dada por Cooper “la calidad es el grado en el cual un objeto (por ejemplo proceso, producto o servicio) satisface un conjunto de atributos o requisitos especificados”.

Este conjunto de atributos juegan un rol relevante durante el desarrollo de software, no basta con obtener productos que satisfagan en el presente las necesidades de los usuarios, sino que es necesario desarrollar teniendo en cuenta aspectos tales como la facilidad de uso y la extensibilidad del mismo. Estos atributos, junto a otros, son los que se consideran a la hora de determinar la calidad de un producto de software.

Algunos ejemplos de falta de calidad de un producto de software son:

• El producto puede ser difícil de comprender y modificar.

• El producto puede ser difícil de usar o fácil de darle mal uso.

• El producto podría ser innecesariamente dependiente de la máquina o tener serias dificultades para integrarse con otros programas.

Cuando se implementa un software, no basta con asegurar que el nuevo sistema incorpora todas las funcionalidades requeridas por los usuarios, como se mencionó en los párrafos anteriores, existe un conjunto de características de

33

calidad que deben tenerse en cuenta. A estas características de calidad se les conoce también como Requisitos No Funcionales (NFR).

Se debe tener en cuenta que existen requisitos no funcionales que se contraponen unos a otros. Por ejemplo, en ocasiones, incorporar mecanismos que fortalezcan la seguridad del sistema puede afectar al rendimiento del mismo, en términos de los tiempos de respuesta obtenidos. Por lo mismo, se deben priorizar y en ocasiones seleccionar los Requisitos No Funcionales que serán considerados a partir de un conjunto de cualidades deseadas.

Asociadas a los atributos de calidad deben existir métricas, que ayuden a obtener un valor de la calidad del software. Actualmente, una vez que el sistema ha sido desarrollado completamente, se aplican estas métricas al producto para determinar en qué grado el requisito de calidad ha sido incorporado, pero esta incorporación ha sido intuitiva y subjetiva, dado que no se realiza mediante procedimientos formales. El problema de esta estrategia radica en que si al aplicar estas métricas, los resultados no son satisfactorios, se debe realizar una modificación en el diseño y/o implementación del sistema, lo que puede generar una gran alza en los costes de desarrollo. Es así como Brito, Moreira y Araújo [41] exponen que la integración tardía de los requisitos no funcionales, puede comprometer algunos principios de la Ingeniería de Software, como por ejemplo, la abstracción, modularidad y reusabilidad.

Dada la gran diversidad de los requisitos de calidad, es posible encontrar distintas clasificaciones de éstos. A continuación, se mencionan algunas de estas clasificaciones propuestas según diferentes autores, con el fin de centrar esta investigación en las cualidades de calidad necesarias para garantizar el funcionamiento del producto software y la correcta definición de los criterios de aceptación que tendrá un proyecto de adquisición.

Según Malan y Bredemeyer en [42], los requisitos no funcionales pueden tipificarse en:

• Restricciones: son características que debe cumplir el sistema y que no son negociables.

• Restricciones contextuales: características del sistema que contendrá al nuevo sistema en desarrollo.

• Cualidades: propiedades o características del sistema que afectan al grado de satisfacción de los usuarios. A su vez, las cualidades pueden clasificarse en dos tipos: las características que el sistema debe satisfacer en tiempo de ejecución (run-time qualities), las cuales deben ser especificadas por los futuros usuarios del sistema; y aquellas que deben considerarse durante el tiempo de desarrollo (development-time qualities) y que deben ser especificadas por el equipo de desarrolladores del producto.

Las cualidades en tiempo de ejecución, se relacionan con cómo de bien se satisfacen los requisitos funcionales, y consideran las siguientes características:

34

• Usabilidad (facilidad de uso, fácil de aprender, eficiencia, etc.).

• Configurabilidad y soportabilidad.

• Correctitud, precisión y disponibilidad.

• Calidad de servicio (tiempo de respuesta, latencia, etc.).

• Seguridad y tolerancia a fallos (protección de la información y de los recursos del sistema).

• Escalabilidad operacional (soporte del incremento de usuarios, o volumen de transacciones, etc.).

Por otro lado, las cualidades en tiempo de desarrollo, se relacionan con las propiedades que deben considerarse durante la creación de los artefactos del proceso de desarrollo se consideran:

• Localización (capacidad de adaptarse a diferencias regionales).

• Modificabilidad o extensibilidad (capacidad de transformación).

• Composición (crear sistemas a partir de plug-and-play).

• Reusabilidad.

Por otro lado, Robertson & Robertson [43] presentan una clasificación de los requisitos no funcionales, realizada después de revisar muchas especificaciones, dando paso a una lista extraída de las propiedades más útiles que los productos deben tener:

• Requisitos de apariencia.

• Requisitos de usabilidad.

• Requisitos de rendimiento.

• Requisitos de mantenibilidad y portabilidad.

• Requisitos de seguridad.

• Requisitos culturales y políticos.

• Requisitos legales.

Chung y Nixon [44] presentan una jerarquía de requisitos no funcionales, como se muestra en la Figura 2. 6.

35

Figura 2. 6.- Jerarquía de Requisitos No Funcionales según Chung y Nixon