Cualidades del software como requerimientos
Casi siempre, los usuarios y/o clientes solo expresarán requerimientos de carácter funcional. Sin embargo, esto no es el único tipo de requerimiento ya que tenemos los no funcionales.
Estos requerimientos no son sencillos de identificar, sobre todo cuando se empieza. Una ayuda que proporciona la ingeniería de software para identificar requerimientos no funcionales son las llamadas cualidades de software que se listan a continuación:
Correcto: Un sistema es correcto si se comporta de acuerdo con la especificación de los requerimientos ncionales que
debería proveer. Esta definición de correcto asume que existe una especificación de requerimientos funcionales del sistema y que es posible determinar en forma no ambigua si las cumple o no.
Es de notarse que esta definición de correcto no toma en consideración el que la especificación en sí misma puede ser incorrecta por contener inconsistencias internas, o no corresponder de forma adecuada a las necesidades para las que fue concebido el programa.
Confiabilidad:La confiabilidad se define en términos del comportamiento estadístico: la probabilidad de que el sistema opere como se espera en un intervalo de tiempo especificado.
Contrariamente a la cualidad de correcto que es una cualidad absoluta, la confiabilidad es relativa. Cualquier desviación de los requerimientos hace que el sistema sea incorrecto, por otro lado, si la consecuencia de un error en el sistema no es seria, el sistema incorrecto aún puede ser confiable.
Robustez: Un sistema es robusto si se comporta en forma razonable aun en circunstancias que no fueron anticipadas en la especificación de requerimientos; por ejemplo cuando encuentra datos de entrada incorrectos o algún malfuncionamiento del hardware.
Un sistema que genere un error no recuperable en tiempo de ejecución tan pronto como el usuario ingrese inadvertidamente una instrucción incorrecta no será robusto, aunque podría ser correcto si en la especificación de requerimientos no se establece la
acción a tomar si se ingresa una instrucción incorrecta.
La robustez es una cualidad difícil de definir, ya que si se pudiera establecer en forma precisa lo que se debiera hacer para obtener un sistema robusto, se podría especificar completamente el comportamiento “razonable”, con lo cual sería equivalente a lo correcto, o a la confiabilidad en el caso ideal mencionado en la definición anterior.
Eficiencia o Desempeño
Un sistema es eficiente si utiliza los recursos en forma económica. El desempeño de un sistema es importante porque afecta su usabilidad, por ejemplo, si es muy lento reduce la productividad de los usuarios, si usa demasiado espacio de disco puede ser muy caro de ejecutar, si utiliza demasiada memoria puede afectar al resto de las aplicaciones que se están ejecutando o ejecutarse demasiado lentamente mientras el sistema operativo intenta balancear el uso de la memoria por parte de las distintas aplicaciones.
Detrás de estos problemas están los límites cambiantes de la eficiencia según cambia la tecnología, ya que la visión de “demasiado caro” cambia constantemente según los avances tecnológicos, actualmente una computadora cuesta bastante menos que hace unos años y
son bastante más poderosas.
Amigabilidad: Un sistema es amigable si un usuario humano lo encuentra fácil de utilizar. Esta definición refleja la naturaleza subjetiva de la amigabilidad: un sistema utilizado por usuarios no experimentados califica como amigable por varias propiedades distintas a las de un sistema utilizado por usuarios expertos.
Verificabilidad: Un sistema es verificable si sus propiedades pueden ser verificadas fácilmente. Por ejemplo, la cualidad de correcto o el desempeño de un sistema son propiedades que interesa verificar.
El diseño modular, prácticas de moificación disciplinadas, y la utilización de lenguajes de programación adecuados contribuyen la verificabilidad de un sistema. La verificabilidad es en general una cualidad interna pero a veces también puede ser externa.
Mantenibilidad: El término mantenimiento es utilizado generalmente para referirse a las modificaciones que se realizan a un sistema luego de su liberación inicial, siendo visto simplemente como “corrección de bugs”. Algunos estudios han mostrado que la mayor parte del tiempo utilizado en mantenimiento es para agregarle al producto características que no estaban
en las especificaciones originales o estaban definidas incorrectamente.
En realidad la palabra “mantenimiento” no es apropiada para el software ya que cubre un amplio rango de actividades que tienen que ver con la modificación de un software existente para lograr una mejora, un término que se aplica mejor a este proceso es “evolución del software”.
Hay evidencia de que los costos de mantenimiento exceden entre el 60% y el 80% del total de los costos del software.
Para analizar los factores que afectan estos costos, es usual dividir el mantenimiento del software en tres categorías: de corrección, de adaptación y de mejora.
Reparabilidad: Un sistema es reparable si permite la corrección de sus defectos con una carga limitada de trabajo.
En el software las partes no se deterioran, y aunque el uso de partes estándares puede reducir el costo de producción del sistema, el concepto de partes reemplazables pareciera no aplicar a la reparabilidad del sistema. Otra diferencia es que el costo del software está determinado, no por partes tangibles sino por actividades de diseño.
Un producto de software consistente en módulos bien diseñados es más fácil de analizar y reparar que uno monolítico, sin embargo, el solo aumento del número de módulos no hace que un producto sea más reparable.
Una modularización adecuada con definición adecuada de interfaces que reduzcan la necesidad de conexiones entre los módulos promueve la reparabilidad ya que permite que los errores estén ubicados en unos pocos módulos, facilitando la localización y eliminación de los mismos.
Evolucionabilidad: Un sistema es evolucionable si acepta cambios que le permitan satisfacer nuevos requerimientos. En el caso de sistemas, en general la implementación del cambio se comienza sin realizar ningún estudio de factibilidad, dejando
únicamente el diseño original y sin actualizar las especificaciones para reflejarlo, lo que hace que cambios futuros sean cada vez más difíciles de aplicar.
La evolucionabilidad es una cualidad tanto del producto como del proceso, aplicado al segundo éste debe ser capaz de adaptarse a nuevas técnicas de gestión y organización, cambios en la educación en ingeniería, etc.
Es una de las cualidades más importantes del software, e involucra otros conceptos como familias de programas cuyo propósito es fomentar la evolucionabilidad.
Reusabilidad: La reusabilidad es similar a la evolucionabilidad: en la segunda se modifica un producto para construir una nueva versión del mismo producto, en la primera se utiliza un producto, posiblemente con modificaciones menores, para construir otro producto.
Es difícil lograr reusabilidad terminado el sistema, por el contrario se debe contemplar al momento de desarrollar los
componentes del software.
Otro nivel de reusabilidad está dado en los requerimientos: al analizar una nueva aplicación se pueden identificar partes que son similares a otras utilizadas en una aplicación previa. También, en el nivel del código se pueden reutilizar componentes desarrollados en una aplicación anterior.
Fuente: Apuntes de Informática IV de la FCA de la UNAM
