Calidad en el software

Calidad en el software ¿Cómo lo logramos,qué medimos?
En teoría los sistemas deberían satisfacer un conjunto de requerimientos, y lo que muchas veces hacemos a un lado es que son esos requerimientos los que definen o mejor dicho deberían definir la arquitectura de nuestro sistema.

Es por eso que en este post quisiera resaltar la importancia de una correcta definición y categorización de los requerimientos.

He de decir que a lo largo de mi experiencia profesional he visto y vivido problemáticas en algunos proyectos por problemas de “calidad” en el software que estamos por entregar, ¿y esto que tiene que ver con los requerimientos y más aun con la arquitectura de nuestra aplicación? Todo, he de decir que todo.

A donde quiero llegar es que la calidad de nuestro producto que entreguemos a los usuarios dependerá de una correcta definición de los requerimientos (lo cual parecería obvio, pero a veces no lo es), y va mas allá de eso.

¿Cuántos de nosotros hemos estado enterados que existen normas y estándares para definir la calidad del software? Bueno espero que ya haya sembrado la semilla de la duda y de esa curiosidad que nos lleva a conocer nuevas y mejores formas de hacer las cosas, empecemos con la carnita.

Sabemos que un requerimiento es una característica de nuestro sistema y se dividen en funcionales y no funcionales.

Existe una norma / estandar (ISO/IEC 9126) que clasifica las características que debemos contemplar en nuestros sistemas de la siguiente forma


.-Funcionalidad :Indica las características que nuestro software debe cumplir y contempla: exactitud, seguridad, interoperabilidad y cumplimiento de normas y estándares.

En esta categoría incluimos las necesidades de negocio a satisfacer

.- Confiabilidad : Indica las capacidades de nuestro software de mantener un nivel de desempeño específico bajo condiciones definidas. Debe contemplar madurez, tolerancia a fallos y recuperación.

1. La madurez se refiere a que nuestro software no experimente interrupciones en el caso de errores internos.
2. Tolerancia a fallos indica la capacidad de controlar los fallos en función de mantener un nivel de comportamiento aceptable de nuestra aplicación.
3. Recuperación indica la capacidad de que nuestro sistema se recupere en caso de error.

En esta categoría deberíamos definir mecanismos de replica para nuestra base de datos, como es que nuestra aplicación apuntara de forma automática al nuevo servidor de BD, saber que nuestra aplicación debe estar disponibles cuantos horas y cuantos días al año.

.- Usabilidad : Indica la capacidad de que nuestro software sea intuitivo, y fácil de entender y usar por nuestros usuarios.

.- Eficiencia : Indica la capacidad de mantener un nivel de desempeño en términos de tiempos de respuestas y cantidad de recursos disponibles.

En esta categoría es donde deberíamos definir una “Baseline” para nuestra aplicación la cual define el comportamiento de nuestro aplicativo con “n” usuarios, con “X” cantidad de memoria, capacidad de red. Capacidad de procesador

.- Mantenibilidad : Indica la capacidad de nuestro software para ser modificado y tener un nivel bajo de riesgo de introducir errores, así como de que estas modificaciones sean fáciles de implementar.

En esta categoría deberíamos prestar atención especial al diseño de nuestras clases, componentes, capas, estilos de arquitectura a utilizar. Proyectos de pruebas unitarias a ser implementados.

.- Portabilidad : Indica la capacidad de que nuestro software sea potable entre plataformas y la capacidad de que coexista.

Como podran ver, el establecer correctamente los requerimientos de nuestro sistema seran el input que necesitamos para empezar a definir la arquitectura de la futura aplicación.

Hace un tiempo estuve involucrado en un proyecto que tenia al menos dos años en desarrollo, mantenimiento y entregas. Me entere en algún momento que el cliente cuestionaba entre otras cosas la usabilidad y parecía que la moda de haber echo un sitio Web no era la solución tecnológica por la que se debió optar, sin duda respondernos las preguntas que nacen de seguir la norma ISO/IEC 9126) habría evitado esa amarga experiencia.

Espero les sea de utilidad