Colabora.NET: Factores en la calidad del software

Factores en la calidad del software

Como bien sabrán ustedes amigos lectores, actualmente estudio Ing. de Sistemas Informáticos, y como tal, es decir, como futuro Ingeniero, siempre me preucupo en incrementar la calidad del sofware en la que me comprometo llevar acabo dentro de un grupo de trabajo, pues asumiendo este rol, deseo decirte que en la ingeniería, se busca la calidad; la ingeniería del software es la producción de software de calidad. Todos deseamos que nuestros sistemas de software sean rápidos, fiables, fáciles de usar, legibles, modulares, estructurados y así sucesivamente. Pero estos adjetivos describen dos tipos de cualidades diferentes.

Por una parte, se consideran cualidades tales como la velocidad o la facilidad de uso, cuya presencia o ausencia en un producto de software puede ser detectada por sus usuarios. Estas propiedades pueden ser denominadas factores de calidad externos.

Otras cualidades aplicables a un producto de software, como la Modularidad o legibilidad son factores internos, perceptibles sólo por profesionales de la informática que tienen acceso al código fuente.

En última instancia, sólo importan los factores externos. Si se una un navegador Web o se vive cerca de una planta nuclear controlada por computadora, importa poco que el software sea legible o modular si los gráficos tardan años en cargarse o si la introducción de datos erróneos hace explotar la planta.La clave para obtener los factores externos radica en los internos: para que los usuarios disfruten de las cualidades visibles, los diseñadores y los implementadotes deben aplicar técnicas internas que aseguren las cualidades ocultas.

1. Una revisión de los factores externos:

1.1 Corrección

La corrección es la cualidad principal. Si un sistema no hace lo que se supone que debe hacer, poco importan el resto de consideraciones que hagamos sobre él – si es rápido, si tiene una bonita interfaz de usuario…

Pero esto es más fácil de decir que de lograr. Incluso el primer paso hacia la corrección es ya difícil: debemos ser capaces de especificar los requisitos del sistema de una forma precisa, lo que es en sí una ardua tarea.

Los métodos que aseguran la corrección son usualmente condicionales. Un sistema de software importante, incluso uno pequeño según los estándares de hoy, implica a tantas áreas que sería imposible garantizar su corrección manejando todas las componentes y propiedades en un solo nivel. En cambio, es necesaria una solución multinivel, en la que cada nivel confía en la corrección de los inferiores:

Hardware ----> Sistema Operativo----> Compilador ----> Sistema de Aplicación

En la solución condicional de la corrección, sólo hay que preocuparse en garantizar que cada nivel sea correcto bajo el supuesto de que los niveles inferiores son correctos.

1.2 Robustez

La robustez complementa la corrección. La corrección tiene que ver con el comportamiento de un sistema en los casos previstos por su especificación; la robustez caracteriza lo que sucede fuera de tal especificación.

La robustez es por naturaleza una noción más difusa que la corrección. Puesto que tiene que ver aquí con casos no previstos por la especificación, no es posible decir, como con la corrección, que el sistema debería “realizar sus tareas” en tal caso; donde las tareas son conocidas, el caso excepcional formaría parte de la especificación y regresaríamos al terreno de la corrección.

Siempre habrá casos que la especificación no contemple explícitamente. El papel del requisito de robustez es asegurar que si tal caso surgiese el sistema no causará eventos catastróficos; debería producir mensajes de error apropiados, terminar su ejecución limpiamente en lo posible.

1.3 Extensibilidad

El software se supone que es soft (blando), y realmente lo es en un principio; nada es más fácil de cambiar que un programa si se tiene acceso a su código fuente.

El problema de extensibilidad es un problema de escala. Para programas pequeños realizar cambios no es normalmente una tarea difícil; pero a medida que el software crece comienza a ser cada vez más difícil de adaptar. La extensibilidad es necesaria porque en la base de todo software encontramos algún fenómeno humano y de ahí su volatilidad.

El cambio es omnipresente en el desarrollo del software: cambios en los requisitos, de nuestra comprensión de los requisitos, de los algoritmos, de la representación de los datos, de las técnicas de implementación. Ofrecer soporte para los cambios es un objetivo básico de la tecnología de objetos.

Aunque muchas de las técnicas que mejoran la extensibilidad se pueden aplicar con pequeños ejemplos, su relevancia sólo se ve con claridad en los grandes proyectos. Hay dos principios esenciales para mejorar la extensibilidad:

Simplicidad del diseño: una arquitectura simple siempre será más fácil de adaptar a los cambios que una compleja.
Descentralización: cuanto más autónomos sean los módulos, más alta es la probabilidad de que un cambio afecte a un solo módulo, o a un número pequeño de módulos, en lugar de provocar una reacción en cadena de cambios en el sistema completo.

1.4 Reutilización

La necesidad de la reutilización surge de la observación de que los sistemas software a menudo siguen patrones similares; debería ser posible explotar esta similitud y evitar reinventar soluciones a problemas que ya han sido encontradas con anterioridad. Capturando tal patrón, un elemento de software reutilizable se podrá aplicar en muchos desarrollos diferentes.

La reutilización tiene una influencia sobre todos los demás aspectos de la calidad del software, ya que al resolver el problema de la reutilización se tendrá que escribir menos software y en consecuencia se podrán dedicar entonces mayores esfuerzos a mejorar los otros factores, tales como la corrección y la robustez.

1.5 Compatibilidad

La compatibilidad es importante debido a que los sistemas software no se desarrollan en el vacío: necesitan interactuar con otros. Pero con mucha frecuencia los sistemas tienen dificultades para interactuar porque hacen suposiciones contradictorias sobre el resto del mundo. Un ejemplo es la amplia variedad de formatos de archivos soportados por muchos sistemas operativos. Un programa puede usar directamente como entrada los resultados de otro sólo si los formatos de archivos son compatibles.La clave de la compatibilidad recae en la homogeneidad del diseño y en acordar convenciones estándares para la comunicación entre programas. Los enfoques incluyen:

Formatos de archivos estándares, como en el sistema Unix, donde cualquier archivo de texto es simplemente una secuencia de caracteres.
Estructuras de datos estándares como en los sistemas Lisp, donde tanto los datos como los programas, se representan mediante árboles binarios.
Interfaces de usuario estándares, como en las diferentes versiones de Windows donde todas las herramientas utilizan un solo paradigma para la comunicación con el usuario, basado en componentes estándares tales como ventanas, íconos, menús, etc.

1.6 Eficiencia

Casi sinónimo de eficiencia es la palabra “rendimiento”. La comunidad del software muestra dos tipos de actitud con relación a la eficiencia:

Algunos desarrolladores tienen una obsesión con las cuestiones de rendimiento y le dedican gran cantidad de esfuerzos a presuntas optimizaciones.
Por otro lado, existe la tendencia de soslayar las cuestiones de eficiencia, como se evidencia en las frases de la industria “hágalo correcto antes de hacerlo rápido” y “de todos modos los modelos de computadoras del año que viene van a ser un 50% más rápidos”.

De manera más general, la preocupación por la eficiencia debe sopesarse con otros objetivos tales como la extensibilidad y la reutilización; optimizaciones extremas pueden hacer al software tan especializado que limite el cambio y la reutilización. Es más, la potencia creciente del hardware de las computadoras nos permite tener una actitud más relajada con respecto a tratar de ganar hasta el último byte o microsegundo.

1.7 Portabilidad (transportabilidad)

La portabilidad tiene que ver con las variaciones no sólo del hardware físico sino más generalmente de la máquina hardware-software, la que realmente programamos y que incluye el sistema operativo, el sistema de ventanas y otras herramientas fundamentales. Muchas de las incompatibilidades existentes entre las plataformas son injustificadas, y convierte a la portabilidad en un asunto primordial tanto para los que desarrollan como para los que usan el software.

1.8 Facilidad de uso

La definición insiste en los diferentes niveles de experiencia de los posibles usuarios. Este requisito plantea uno de los mayores retos de los diseñadores de software preocupados por la facilidad de uso: cómo proporcionar explicaciones y guías detalladas a los usuarios novatos sin fastidiar a los usuarios expertos que quieren ir directo al grano.

Una de las claves de la facilidad de uso es la simplicidad estructural. Un sistema bien diseñado, construido de acuerdo a una estructura clara y bien pensada, tiende a ser más fácil de aprender y usar que uno confuso.

Los buenos diseñadores de interfaces siguen una política prudente. Hacen las menos suposiciones posibles sobre los usuarios. Cuando se diseña un sistema interactivo, se debe esperar que los usuarios sean miembros de la raza humana y que sepan leer, mover un ratón, presionar un botón y teclear (lentamente); no mucho más. Si el software está dirigido a un área especializada de aplicación, se puede dar por supuesto que los usuarios están familiarizados con sus conceptos básicos. Pero incluso esto es arriesgado.

1.9 Funcionalidad

Uno de los problemas más difíciles a los que se enfrenta un jefe de proyecto es conocer cuanta funcionalidad es suficiente. La presión para ofrecer más facilidades (conocida como featurism), está constantemente presente. Sus consecuencias son malas para los proyectos internos, donde las presiones vienen de los usuarios de la misma compañía, y son peores para los productos comerciales, ya que la parte más destacada de los análisis comparativos suele ser una tabla donde se enumeran una por una las propiedades que ofrecen los distintos productos analizados.

El featurism es realmente la combinación de dos problemas, uno más difícil que el otro. El problema más fácil es la pérdida de consistencia como consecuencia de estar añadiendo nuevas propiedades, lo que puede afectar a su facilidad de uso. Los usuarios se quejan con razón de que toda la parafernalia que acompaña a una nueva versión de un producto lo hace tremendamente complejo. Tales comentarios no deberían preocuparnos en exceso, puesto que las nuevas propiedades no surgen de la nada: la mayor parte de las veces han sido solicitadas por los usuarios – otros usuarios. Lo que a unos les puede resultar algo superfluo puede ser una facilidad indispensable para otros.

La solución aquí es trabajar una y otra vez sobre la consistencia del producto global, tratando de que todo encaje en un molde general. Un buen producto software está basado en un número pequeño de potentes ideas; incluso si tiene muchas propiedades especializadas, éstas deberían explicarse como consecuencia de los conceptos básicos. El “gran plan” debe estar visible y todo debería ocupar su sitio dentro de él.

1.10 Oportunidad

La oportunidad es una de las mayores frustraciones de nuestra industria. Un gran producto software que aparece demasiado tarde puede no alcanzar su objetivo. Esto es cierto en otras industrias también, pero pocas evolucionan tan rápidamente como el software.La oportunidad es todavía, para grandes proyectos, un fenómeno poco común. Cuando Microsoft anunció que la última versión de su principal sistema operativo, que llevaba realizando varios años, saldría al mercado un mes antes de lo previsto, el suceso fue lo suficientemente relevante como para encabezar los titulares de Computer World.

1.11 Otras cualidades:

Además de las cualidades analizadas, existen otras que afectan a los usuarios de sistemas software y a la gente que compra estos sistemas o encarga su desarrollo. En particular:

Verificabilidad: es la facilidad para preparar procedimientos de aceptación, especialmente datos de prueba y procedimientos para detectar fallos y localizar errores durante las fases de validación y operación.
Integridad: es la capacidad de los sistemas software de proteger sus diversos componentes (programas, datos, etc.) contra modificaciones y accesos no autorizados.
Reparabilidad: es la capacidad para facilitar la reparación de los defectos.
Economía: junto con la oportunidad, es la capacidad que un sistema tiene de completarse con el presupuesto asignado o por debajo del mismo.

2. Sobre la documentación:

En una lista de factores de calidad del software, uno podría esperar encontrar la presencia de una buena documentación como uno de los requisitos. Pero éste no es un factor de calidad separado; la necesidad de documentación es una consecuencia de otros factores de calidad vistos en el acápite anterior. Se pueden distinguir tres tipos de documentación:

La necesidad de documentación externa, que permite a los usuarios conocer la potencia de un sistema y usarlo convenientemente, es una consecuencia de la definición de facilidad de uso.
La necesidad de documentación interna, que permite a los desarrolladores de software comprender la estructura e implementación de un sistema, es una consecuencia del requisito de extensibilidad.
La necesidad de documentación de la interfaz de un módulo, que permite a los desarrolladores de software comprender las funciones proporcionadas por un módulo sin tener que comprender su implementación, es una consecuencia del requisito de reutilización. También se desprende de la extensibilidad, ya que una documentación de la interfaz de un módulo permite determinar cuándo cierto cambio afecta a un determinado módulo.

En lugar de tratar la documentación como un producto propio del software, es preferible producir software lo más autodocumentado posible. Esto se aplica a los tres tipos de documentación:

Incluyendo facilidades de “ayuda” en línea y siguiendo normas para interfaces claras y consistentes, se alivia la tarea de los autores de los manuales de usuario y de otras formas de documentación externa.
Un buen lenguaje de implementación puede eliminar muchas de las necesidades de documentación interna si favorece la claridad y la estructura.
La notación soportará la ocultación de información y otras técnicas para separar la interfaz de los módulos de su implementación. Será posible entonces utilizar herramientas para producir automáticamente documentación de la interfaz del módulo a partir del texto de los módulos.

Espero que lo aportardo le sea de utilidad. Saludos desde Trujillo - Perú.

Nos vemos

DCE3 - Percy Reyes

No olvides de darme tu voto en PanoramaBox, de esta manera seguiré compartiendo contigo lo que voy aprendiendo. Gracias.