 |
No
basta saber, se debe también aplicar. No es suficiente querer, se debe
también hacer. |
|
|
No
basta saber, se debe también aplicar. No es suficiente querer, se debe
también hacer. |
Para DocIRS, un programador debe participar del análisis de los problemas delineados por el ingeniero de procesos en términos de los requerimientos detallados. Desde ahí va diseñando la estrategia a seguir en la estructura del programa. Codifica las instrucciones implementando algoritmos en el lenguaje de programación adecuado. Verifica la lógica del programa preparando rutinas de prueba. Revisa, depura y corrige los programas. Evalúa y modifica los programas existentes para tomar en cuenta los cambios producidos en los requerimientos del sistema. Finalmente prepara el documento base de la ayuda de usuarios. Nótese que un programador debe comprender y expresarse a través de un lenguaje de alta programación. Este conocimiento puede ser por oficio práctico, intuición o por estudio formales . Los lenguajes de programación utilizan formalización matemática, tanto en su estructura como en su simbología. Sus convenciones y usos se realizan especialmente utilizando leyes algebraicas, tales como la Lógica de Bool, particularmente Algebra de Proposiciones, Teoría de Conjuntos, Funciones (algebra y sus propiedades), Series Numéricas, Recursividad, etc. y por tanto un programador trabaja fundamentado en conceptos matemáticos. Cualquier consideración del proceso de programación mismo debe comenzar aislando cada una de sus fases componentes. Se identifica las siguientes cinco fases:
El análisis del problema se refiere a
la etapa del proceso en la que el programador toma conocimiento del problema
antes de proceder a desarrollar una solución. Es un proceso de
“introducción”, de naturaleza cognoscitiva y muy difícil de describir. Son
demasiados los programadores que recorren esta etapa muy rápidamente, lo que
hace que entiendan mal o malinterpreten las especificaciones. Algunos
programadores prefieren devolver las especificaciones del problema al
diseñador, para reducir la posibilidad de malentendido. Los errores que se
cometen en esta etapa son con mucha frecuencia difíciles de detectar y
consumen mucho tiempo cuando se les trata de remediar en las etapas
posteriores. La segunda etapa, el desarrollo de la solución, es eminentemente creativa. Aquí se debe hacer hincapié en la formulación del algoritmo antes que en su codificación en un lenguaje de programación en particular. Aunque algunos podrían argumentar que la habilidad para resolver problemas es algo innato y que es difícil educar o mejorar la creatividad, existe suficiente evidencia en el sentido de que algunos enfoques sistemáticos tienen mucho valor. También es una alternativa recurrir a desarrollos
anteriores hechos para otras soluciones (la librería propia)
y desde allí comenzar el proceso de creación. Siempre y cuando el problema
central haya sido resuelto realmente, puesto que si no es así esta situación
acarreará problemas en las fases posteriores. Otro punto de suma importancia
en esta etapa, es el definir la arquitectura del modelo de datos, las
relaciones lógicas básicas y las pautas a seguir en las transacciones con la base(s) de datos que tendrá la aplicación.
(Asumimos que en esta etapa, ya debe estar delineado el conjunto de clases
de funciones que tendrá el sistema, y que posteriormente se transformarán en
las entidades u objetos). La tercera etapa identificada es
la construcción de la solución desarrollada en forma de un
programa real (o código). Considerando que la solución ha sido bien
definida, este proceso es casi directo, pues es un proceso mental inmediato
de las fases anteriores. Mediante rutinas, funciones, script, procedimientos
y reglas del lenguaje de programación, se va ensamblando la aplicación de
acuerdo con los estándares de estilo y de estructura. La cuarta fase se refiere a la revisión y corrección del programa sea en de Ambiente de Desarrollo o Prueba. Es inevitable realizar pruebas mientras va construyendo las componentes de la aplicación. Todo programador experto prueba no sólo mentalmente cada instrucción cuando la está escribiendo, sino que va ejecutando las rutinas de cualquier módulo o sección de su programa antes de proceder a pasar a Ambiente de Prueba, donde probarán los que establecieron el diseño funcional del sistema. La prueba de las aplicaciones nunca es sencilla; Es natural que las pruebas muestran la presencia de errores y nunca se puede demostrar la ausencia de ellos. Una prueba con éxito sólo significa que no se detectaron errores bajo las circunstancias especiales de dicha prueba; esto no significa nada frente a otras circunstancias. Aunque se sabe, que el programado repite múltiples veces sus formas de prueba de lo que construye y siempre dejará espacios que encontrará un tercero. En teoría, la (única manera en que las pruebas pueden demostrar que un programa es correcto es que se examinen todos los casos posibles (lo cual se conoce como una prueba exhaustiva), situación que es imposible técnicamente, incluso para los programas más simples. Significa esto que las pruebas son inútiles? Definitivamente, no. El programador puede hacer mucho por reducir el número de casos a probar a partir del número requerido por una prueba exhaustiva. Tomando con mucho cuidado y seleccionando apropiadamente el diseño de los casos de prueba, puede reducirse el número de ellos, haciendo posible una prueba razonable con un número relativamente pequeño de casos. La prueba de un programa es una tarea tan creativa como su mismo
desarrollo, por lo que debe considerarse con la misma diligencia y
entusiasmo. Algunos principios de las pruebas son claros: trátese de iniciar
las pruebas de un programa con una mentalidad de saboteador, casi
disfrutando la tarea de buscar un error. Hay que sospechar de todo. Los
casos de prueba deberían diseñarse a partir de las especificaciones
originales, en lugar del programa mismo; si se efectúan a partir del
programa, algunos aspectos del problema que han sido pasados por alto
durante su construcción también lo serán cuando se le pruebe. Para reducir
las posibilidades de que esto ocurra en las compañías profesionales de
programación, los encargados suelen insistir en que sean personas diferentes
a los programadores originales quienes tengan a su cargo la prueba de los
programas. Los usuarios de los programas disponen, con frecuencia, de sus
propios datos de prueba desarrollados, independientemente, para usarlos
cuando el programa esté a su disposición. Téngase en cuenta que la
contraparte del cliente evalúa muy mal al equipo de desarrollo o proveedor
cuyas aplicaciones no son capaces de pasar las pruebas de los usuarios. Por
eso de cualquier forma que se haga, una prueba completa antes de pasar a la
revisión del cliente es una parte esencial de los proyecto de programación. La quinta etapa del proceso de
programación, el mantenimiento del programa. Sin embargo, su
importancia en el trabajo real nunca debe despreciarse. En general, el costo
de mantenimiento de un programa de uso generalizado es del orden del 40% o
más del costo de su desarrollo”. Al contrario de lo que sucede con el
mantenimiento de hardware, el mantenimiento de los programas no se refiere a
la reparación o cambio de partes deterioradas, sino a las modificaciones que
deben hacerse a los defectos del diseño, lo cual puede incluir el desarrollo
de funciones adicionales para reunir nuevas necesidades. El tiempo de los
desarrolladores para producir nuevos programas se ve siempre afectado por el
tiempo que deben dedicar al mantenimiento de los programas viejos. La
inevitabilidad del mantenimiento debe reconocerse y, en consecuencia, deben
realizarse las acciones que sean necesarias para reducir el tiempo que ello
implica. Bibliografía:
|
A fin de poder asegurar que un sistema cumpla con el
sistema
requerido por el cliente, no basta simplemente con un levantamiento y
diseño funcional, especificación de los casos de uso y descripción de procesos. Es imprescindible
la
comunicación con el Equipo de Desarrollo. Es decir, con la
participación del programador. (