2. 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.
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.
3. Cualquier consideración del proceso de programación mismo debe comenzar aislando cada
una de sus fases componentes. Se identifica las siguientes cinco fases:
4. 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.
5. 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).
6. 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.
7. 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.
8. EL MANTENIMIENTO DEL PROGRAMA
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.
