30/10/13 Acerca de las fases del proceso de programación

No basta saber, se debe

también aplicar. No es
suficiente querer, se debe
también hacer.
Johann Wolfgang Goethe

ACERCA DE LAS FASES DEL PROCESO DE PROGRAMACIÓN

José Enrique González Cornejo
23 de abril 2009

Resumen:

El artículo intenta establecer las fases básicas que

componen el proceso de programación. La
formulación de estas fases se define desde la
experiencia de DocIRS y no como una metodología
absoluta. A este fin, primeramente se esboza una
definición de un programador actual. Posteriormente
se describen y analizan las principales características
de 5 fases: Análisis del problema; Desarrollo de la
solución; Construcción de la solución en forma de
programa; Prueba o Testing, Mantenimiento

Indice

LAS FASES DEL PROCESO DE PROGRAMACIÓN

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. (Ver
Perfil del Analista Programador DocIRS)

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

www.docirs.cl/acerca_fases_proceso_programacion.htm 1/4
30/10/13 Acerca de las fases del proceso de programación

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:

1. Análisis del problema

2. Desarrollo de la solución
3. Construcción de la solución en forma de programa
4. Prueba
5. Mantenimiento

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.

www.docirs.cl/acerca_fases_proceso_programacion.htm 2/4
30/10/13 Acerca de las fases del proceso de programación

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.
www.docirs.cl/acerca_fases_proceso_programacion.htm 3/4
30/10/13 Acerca de las fases del proceso de programación

Bibliografía:

An algorithmic Approach
Department of Computational Science.
University Saskatchewan
Jean-Paul Tremblay
Richard B. Bunt

Sistema de Gestión de la Calidad

ISO 9001, KUALITOS E.I.R.L.
Santiago- Chile.

Nomenclatura de DocIRS para la Programación

Acerca del Estilo en Programación.

Acerca de la Calidad de una Aplicación

Programación con Diseño Modular o Top-Down

Construcción de Aplicaciones sobre Plataforma Internet Enfoque y Metodología de

DocIRS.

Estrategia Simple de Diseño PMO

RobotDocIRS

Síntesis gráfica de la Metodología General de DocIRS

Ver Video con Entrevista a DocIRS para UCV Televisión

www.docirs.cl/acerca_fases_proceso_programacion.htm 4/4