 |
No puede el hombre
sentirse a gusto sin su propia aprobación. |
|
No puede el hombre
sentirse a gusto sin su propia aprobació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 evasivo. Si se interrogara a muchos 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)
Las Visiones de la Calidad de un sistema, según Daniel Pezoa Duran (KUALITOS E.I.R.L Especialista en Certificación de Calidad ) son:
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. La solución casi completa 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 las fases de diseño, revisión e instalación del sistema. 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 crean tres (o más) ambientes físicos (y filtros) antes de entregar. En efecto:
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). 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. 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 ofrece el motor de datos, sobre el cual se está montando la aplicación (procedimientos almacenados, triggers, indización full-text, sts, etc..), trabajar en capas y orientados al objeto. 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.
Nota Acerca del perfil del Analista Programador DocIRS
El programador DocIRS, debe tener conocimiento y Oficio en: En síntesis: Administración de Base de Datos, Ambiente de Redes, Técnicas de programación, Programación orientada a Objetos, Desarrollo de aplicaciones en Internet, Lenguaje de Tercer o Cuarta Generación, Análisis y diseño de sistemas.
|
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 en la
cual va a emplearse el sistema. Los desarrolladores nunca hacen esto en forma deliberada
(nadie disfruta rastreando 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.