Home

No puede el hombre sentirse a gusto sin su propia aprobación.
Mark Twain


ACERCA DE LA LA CALIDAD DE UNA APLICACION

José Enrique González Cornejo
18 de abril 2009

Resumen:

El artículo trata de responder la pregunta ¿Qué es un buen programa de computación? . La respuesta se formula desde el punto de vista del constructor, estableciendo y fundamentando las principales características que se deben cumplir para comenzar a lograr calidad en una aplicación . Es decir, cuál es estándar mínimo de calidad que requiere un programa computacional.

 

Indice

Introducción

Previamente a las consideraciones de los métodos que existen para mejorar la calidad de las aplicaciones, es conveniente tratar de definir qué es lo que se está buscando.

El concepto es ambiguo. Si se preguntara a varios equipos de desarrollo de sistemas: ¿Cuáles son las características de un buen programa?, probablemente se recibiría una gran variedad de respuestas, según el gusto personal y la experiencia de las personas entrevistadas. Sin embargo, cierta clase de respuestas pueden presentarse con mayor frecuencia. (Ver Acerca del Estilo en Programación)

visiones_calidad.jpg

Las Visiones de la Calidad de un sistema1, son:

  • La Calidad Necesaria o requerida: Qué calidad requiere el cliente o usuario.

  • La Calidad Programada o especificada: La calidad que se intenta conseguir.

  • La Calidad Realizada: La calidad que se ha conseguido.

  • La Calidad Percibida: Es la calidad, que el cliente valora. Es decir, el objetivo es que las tres visiones coincidan.


La aplicación debe funcionar

La característica más simple e importante de un programa es que funcione. Esto puede parecer obvio, pero es difícil de asegurar en los programas de algún tamaño considerable.

Circulan en el ambiente muchas historias de errores catastróficos y muy costosos de programas computacionales. Tales incidentes no sólo reflejan las fallas de la industria como un todo, sino que también contribuyen en gran medida a robustecer el recelo y la desconfianza que tiene el público hacia los sistemas (y en consecuencia de los clientes hacia los fabricantes de sistemas).

Los desarrolladores deben ser muy cuidadosos en el sentido de que el programa, rutina, procedimiento, página o script instalado sea efectivamente el que se necesita. Es muy fácil sumergirse de tal manera en los detalles que llegue a perderse el concepto original de las especificaciones del cliente. (Ver Método Simple-DocIRS)

Una solución sobrecargada del problema planteado puede originar incidentes desafortunados y/o clientes insatisfechos. Es muy importante que las especificaciones y/o requerimientos (que pueden, de hecho, variar con el tiempo) sean continuamente revisadas durante todas sus fases.

Las especificaciones mismas pueden ser erróneas o incompletas, o simplemente pueden ser malinterpretadas. Debe tenerse cuidado de no adornar el programa con características no pedidas en forma específica (pero sensacionales visualmente), porque esto significa una fuente adicional de error. Hoy las normas y buenas prácticas. (Ver  Estrategia del Diseño Simple)

Por ejemplo, crear tres (o más) ambientes físicos (y filtros) antes de entregar. En efecto:

  • Prototipo (Paginas o Formularios, conjunto de objetos, Navegación. Ver RobotDocIRS)

  • Ambiente de Desarrollo (Aquí los propios programadores revisan)

  • Ambiente de Prueba (Aquí revisa el ingeniero o persona que juega el rol de contraparte del cliente)

  • Ambiente de Pre-Producción (Aquí se revisa conjuntamente con el cliente y un grupo de usuarios. También llamado Piloto. Ver Metodología DocIRS)

  • Ambiente de Producción (Aquí se implanta el sistema en la organización)
    Volver al Inicio

La aplicación no debe tener dificultades

Muchos desarrolladores aceptan las pequeñas dificultades (o fallas) de los programas como una consecuencia natural de la condición humana, y consideran su corrección como una situación inevitable de la vida. Sin embargo, no hay ninguna razón para que esto suceda.

 Las imágenes de diabólicos duendes o extraterrestres que en forma muy secreta introducen errores en los programas asaltan con frecuencia la imaginación cuando de hecho, son los mismos desarrolladores los responsables frecuentes de ellos por descuido, desaciertos en la notación, copiar y pegar de otras fuentes en forma mecánica, carencia de separación de objetos y funciones, falta de comprensión de las especificaciones o no anticipar alguna situación particular (Caso de Uso) en la cual va a emplearse el sistema.

Obviamente, los desarrolladores nunca hacen esto en forma deliberada (nadie disfruta con los errores) y, de hecho, ellos son los más indicados para evitar la mayor parte de ellos. A este efecto, se debe implantar un estilo y práctica antibugging, cuya filosofía consiste en tratar de evitar los errores desde el comienzo.

A pesar de que esto puede hacerse, es evidente que es responsabilidad del programador es asegurar que la aplicación está libre de errores.

Buena parte de la investigación en ciencia de la computación ha estado dirigida hacia la búsqueda de pruebas formales, matemáticas, de la validez de los programas. Se ha establecido que estas pruebas son posibles; sin embargo, los procedimientos son largos y dificultosos, y pocas veces prácticos en las aplicaciones reales. Cuando éste sea el caso, el programador debe recurrir a otros métodos, como las pruebas para establecer la validez de sus módulos y rutinas.(Ver Construcción de Aplicaciones sobre Plataforma Internet Enfoque y Metodología de DocIRS).
Volver al Inicio

La aplicación debe estar bien documentada

Es muy importante que una aplicación o sistema esté bien documentado. La documentación existe para ayudar a comprender o usar un programa. Esto no sólo es importante para los encargados de dar mantenimiento o modificar los programas; también puede ser de gran valor para el desarrollador mismo .Tener los planos con el Modelamiento, Diseño Funcional, Casos de Uso,..etc (Ver UML). Nuestro punto de vista es evitar la Programación Extrema. (Ver Estrategia de Diseño Simple)

La mayoría de los desarrolladores se ven forzados a prestar atención simultánea a diferentes asuntos, ya sean programas distintos, diversas partes de un mismo programa e, incluso, diferentes tareas de su trabajo. Los detalles de los programas en particular, o algunas partes especiales de los mismos, pueden olvidarse fácilmente o confundirse si no se tiene la documentación apropiada.

La documentación puede tenerse en dos formas: la documentación externa, que incluye cosas como manuales de referencia, descripciones de los algoritmos, diagramas de flujo, proyectos de trabajo y aspectos similares; y la documentación interna, que aparece en la lista de instrucciones misma del programa (esencialmente, el código del programa, más algunos comentarios Ver Acerca del estilo en Programación).

El valor de la documentación interna no debe subestimarse. Para un programa cualquiera, el código fuente con sus funciones e instrucciones constituye la primera línea de la documentación, por lo cual se ha hecho hincapié en la importancia de que los códigos fuentes sean fácilmente legibles. La legibilidad es el criterio más sencillo para evaluar la calidad de un programa; si el programa es fácil de leer, probablemente es un buen programa; si es difícil de leer, no es un buen programa. (Ver Nomenclatura de DocIRS para la Programación). La documentación externa está dirigida con más frecuencia a los usuarios y administradores del programa, quienes no necesitan ni quieren saber nada del código fuente, y sólo desean conocer qué hace el programa y cómo trabaja. La documentación externa proporciona una importante descripción complementaria.
Volver al Inicio

La aplicación debe ser eficiente

En este artículo hemos tratado la construcción de aplicaciones, siempre de un punto de vista de los códigos . Sin embargo, es importante remarcar que lo fundamental de una aplicación es el usuario final. Es decir, la eficiencia también dice relación con la usabilidad de las funcionalidades, esto implica que las soluciones del programador deben se amistosas y simples.

En efecto, no es eficiente que el usuario tenga que ingresar una estructura de complicada sintaxis, como por ejemplo: "[prefijo]_[nombre]_[version]_ddmmaaa.zip" (y aun peor, si no lo ingresa con esa estructura el sistema le emite un error); que el cliente se vea obligado a presionar tres teclas al mismo tiempo para lograr una operación; que tenga que pasar por tres pantallas, para llegar obtener un formulario donde finaliza la acción; que la acción esté llena de validaciones innecesarias al momento de grabar,etc…

Actualmente, con el hardware existente y la potencialidad de los lenguajes de programación orientados al objeto, realmente se puede facilitar el trabajo de los diseñadores, de los constructores y fundamentalmente de los clientes. Siempre se debe tener presente que la ponderación de la Calidad Percibida por el cliente es lo que más se valora.

El asunto de la eficiencia es muy complejo. En los primeros días de la computación, las máquinas eran lentas y pequeñas en comparación con los estándares actuales. Los programas tenían que ser diseñados con mucho cuidado para aprovechar al máximo los escasos recursos disponibles de tiempo y espacio de almacenamiento. Los desarrolladores debían gastar horas tratando de eliminar secciones y ahorrar con ello tiempo de ejecución de sus programas, o debían comprimir los programas en un pequeño espacio de memoria de la máquina. La eficiencia de un programa, determinada las más de las veces por medio del "producto espacio tiempo", constituía el mérito primero.

Hoy la situación ha cambiado en forma drástica. Los recursos de hardware y herramientas de optimización han ido disminuyendo continuamente, mientras que los recursos humanos se han elevado y los estándares de lenguajes de alta programación se han universalizado. El tiempo de ejecución y el espacio disponible de memoria ya no son recursos tan escasos como antes, hoy se hace más hincapié en el ancho de banda. En todo caso, se debe estar siempre atento a realizar ahorros que podrían derivarse de la inclusión de una técnica diferente de solución, como la elección hecha para reemplazar la técnica de búsqueda lineal por la más eficiente de búsqueda binaria, aunque no siempre significa un ahorro apreciable para el programador.

Otro caso recomendable es el de  utilizar al máximo los recursos probados que ofrecen los motores de datos, sobre el cual se está montando la aplicación (procedimientos almacenados, triggers, indización full-text, sts, etc..), trabajar en capas, orientados al objeto, con servicios. En síntesis,  tratar de mejorar cada detalle en aras de la eficiencia de su programa.

A pesar de ello, aún hay muchos desarrolladores que siguen cultivando la optimización del producto espacio tiempo, y como resultado producen un código de programación innecesariamente complejo. Un programa que no trabaje o que sea difícil de mantener debido a este código tan rebuscado, es sin duda alguna, un programa de baja calidad, independientemente de su producto espacio tiempo. Es decir, la rutinas que conforman una aplicación deben se simples y concisas como así mismo la lógica global que las articula.

Por tanto, la calidad de una aplicación tiene muchas facetas. Sin duda es importante que un programa trabaje correctamente y que sea confiable, es decir, que reúna todos los requisitos exigidos y que los errores inesperados ocurran muy rara vez y no sean evidentes. Sin embargo, el asunto no concluye aquí. La evolución de los programas, es un fenómeno real. Los programas parecen necesitar un procesamiento continuo de mantenimiento y modificación (que también debe tener un registro documental de modificaciones y cambios) para a mantenerse al día con los requerimientos cambiantes de la tecnología y, con la instalación de ellos en las máquinas.

Las capacidades de modificación y mantenimiento son características esenciales de los programas reales. Que un programa sea fácil de leer y de comprender son prerrequisitos importantes para lograr su mantenimiento, modificación apropiados, articulación con nuevos actores incorporados e integración con otros sistemas.

En resumen, se desean programas correctos, confiables, fáciles de mantener, modificables, legibles y comprensibles.
Volver al Inicio



Bibliografía:

1Según Daniel Pezoa Duran (KUALITOS E.I.R.L Especialista en Certificación de Calidad )