Calidad De Software

Introducción a Calidad de Software

En una entrada anterior yo estube hablando un poco sobre la industria del soft, y sobre los componentes, hoy en día, pensar una industria que no trabaje basando su desarrollo en componentes, por las evidentes razones que mensioné en la entrada anterior.

En casos conocidos, podemos apreciar como windows a partir de 98 tiene su modelo de componentes bien formado, y empieza a basar todo su sistema en componentes, empaquetados en archivos conocidos como dlls.

Podemos apreciar sus ventajas con las actualizaciones automáticas, donde gracias a estas dlls es posible implementar extensibilidad en su correcta expresión, de modo que modificar una dll para que haga una tarea bastante diferente y reemplazar una vieja sin tener que modificar el programa es muy simple.

Antes de ayer asistí a una charla en un Instituto de Formación Técnica Superior, que daba Gabriel Pimentel, donde demostró la simplicidad y utilidad de las dlls, creó un programa que utilizaba una dll que también creó para fines demostrativos (todo ésto en c++) cargó la dll y la utilizó en su programa original, compiló el programa, y luego cambió completamente la dll para que hasta cambie de ser modo consola a modo visual creando una ventanita, reemplazó la dll anterior por la nueva, y el programa original la utilizó sin inconvenientes utilizando las nuevas funciones de dicha dll.

Lo interesante de la cuestión es como separó de una forma muy impresionante la dll que emulaba un sensor y el programa que usaba dicho sensor, creó un pequeño modelo de componentes para demostrar la funcionalidad de ésto, luego simplemente cambió el código de la dll, lo compiló, y reemplazó la anterior, y como por "arte de magia" todo su modelo de componentes "comprendió" que estaba ante una nueva versión que incluía una ventana entre otras cosas, para notificar que había llegado al máximo el sensor.

Sin tirar ningún error utilizó dicha dll con la nueva funcionalidad.

Notarán en éste ejemplo algo muy interesante, nos permite pensar a los componentes y a los que usan componentes como lineas separadas de producción, como en una cadena de fabricación de autos, hay una linea de creación de puertas, una linea que fabrica carrosería, y luego se pueden comprar las ruedas a otra empresa, todo esto pasa por una linea de ensamblaje y llega al producto final.

Es muy parecido a lo que es una industria cualquiera, se puede crear un componente y evolucionar por forma propia independientemente de cómo y para qué lo use quien lo use, y si el que usa dicho componente cambia, no va a haber problemas. porque todo se ensambla, además se puede comprar nuevos componentes a otros fabricantes y aquí empieza laindustria del software.

Y aquí aparece calidad, uno no puede desarrollar un componente que no cumpla con loscriterios de calidad, porque solo generaría un monton de inconvenientes, lo mismo pasa en general, si programas aunque no estés basado en componentes, sin calidad, tu código te dará muchos problemas a la hora de evolucionar, ampliarse o cambiar de contexto.

Programar sin calidad, es como hacer malabares con granadas sin tener el seguro puesto, y es una fábrica de monsters (puede ver la referencia aquí para saber de que hablo cuando comento esto).

Hay dos tipos de criterios de calidad, los criterios externos e internos, es una mera forma de clasificarlos para que se den una idea, los externos son aquellos criterios que el usuario del sistema ve, tales como si tiene una interfaz buena y simple que no vuelva loco al usuario, si responde a las necesidades del usuario, etc. Pero estos criterios en realidad no son los que definimos, ya que no tienen mucho sentido.

Los importantes son los criterios de calidad que nosotros vemos, si nosotros armamos un código sin calidad o con calidad, los únicos que apreciaremos esto somos nosotros.

Hay muchos modelos de criterios de calidad, pero en resumen y juntando todo lo más importante podemos definir los siguientes 7:

Corrección

Robustez

Extensibilidad

Reusabilidad

Compatibilidad

Eficiencia

Otros factores.

Cada uno de ellos será explicado en futuras publicaciones.

1º Criterio de calidad: Corrección

Buenas tardes, siguiendo con la linea que llevo de publicaciones, y ya hecha la introducción a calidad, hablaremos del primer criterio el criterio de la Corrección

En primera instancia daré la definición:

Corrección:

Corrección es la habilidad de una entidad de software de ejecutar exactamente su tarea, tal como se ha sido definida por la especificación y requerimientos.

A partir de esta definición explicaré un poco de que se trata.

La corrección es claramente el primer aspecto de calidad a considerar. Si un producto no hace lo que se supone que debe hacer, cualquier otra consideración acerca de él carece de interés. Este objetivo es más fácil de establecer que de lograr, su logro demanda fundamentalmente que los requerimientos del sistema se expresen de una manera formal y verificable.

Los métodos para asegurar la corrección usualmente serán condicionales. Un sistema de software aún de pequeña escala, abarca tantas áreas que sería imposible garantizar su corrección al tratar con todos los componentes del sistema en un solo nivel, en su lugar se requiere, un conjunto de enfoque por niveles.

En éste enfoque condicional solo garantizamos que cada nivel es correcto sobre la base de asumir que los niveles inferiores lo son. Esta es la única técnica realista, usted no puede garantizar que un programa en un lenguaje de alto nivel X es correcto a menos que se pueda asumir que el compilador utilizado implementa X correctamente. Esto no implica que creamos ciegamente en el compilador, sino que simplemente separamos los dos componentes del problema: La corrección del compilador y la corrección del programa relativa a la semántica del lenguaje.

En un desarrollo real intervienen más niveles, el desarrollo de software descansa en la utilización de componentes reusables que pueden ser utilizados en diferentes aplicaciones, éste enfoque condicional prueba ser de utilidad en entornos reales.

2º

...