Pasos para la soluci�n de problemas

El proceso de resoluci�n de un problema con una computadora conduce a la escritura
de un programa y a su ejecuci�n en la misma. Aunque el proceso de dise�ar programas
es esencialmente un proceso creativo, se pueden considerar una serie de fases o pasos
comunes, que generalmente deben seguir todos los programadores.Las siguientes son
las etapas que se deben cumplir para resolver con �xito un problema de programaci�n:

Definici�n del problema 
An�lisis del problema 
Selecci�n de la mejor alternativa 
Diagramaci�n 
Prueba de escritorio 
Codificaci�n 
Transcripci�n 
Compilaci�n 
Pruebas de computador 
Documentaci�n externa

1.- DEFINICI�N DEL PROBLEMA 

Est� dada por el enunciado del problema, el c�al debe ser claro y completo. Es
importante que conozcamos exactamente que se desea del computador; mientras qu�
esto no se comprenda, no tiene caso pasar a la siguiente etapa.

2.- AN�LISIS DEL PROBLEMA 

Entendido el problema (que se desea obtener del computador), para resolverlo es
preciso analizar: 

Los datos o resultados que se esperan. 
Los datos de entrada que nos suministran. 
El proceso al que se requiere someter esos datos a fin de obtener los resultados 
esperados. Areas de trabajo, f�rmulas y otros recursos necesarios. 

Una recomendaci�n muy pr�ctica es el que nos pongamos en el lugar del computador,
y analizar que es necesario que me ordenen y en que secuencia, para poder producir
los resultados esperados. Tambi�n da buenos resultados hacer similitudes con la 
labor de un empleado que hace el mismo trabajo que deseamos programarle al computador.


3.- SELECCI�N DE LA MEJOR ALTERNATIVA 

Analizado el problema, posiblemente tengamos varias formas de resolverlo; lo importante
es determinar c�al es la mejor alternativa: la que produce los resultados esperados en 
el menor tiempo y al menor costo. Claro que aqu� tambi�n es muy v�lido el principio de 
que las cosas siempre se podr�n hacer de una mejor forma.


4.- DIAGRAMACI�N 

Una vez que sabemos c�mo resolver el problema, pasamos a dibujar gr�ficamente 
la l�gica de la alternativa seleccionada. Eso es precisamente un Diagrama de Flujo: la
representaci�n gr�fica de una secuencia l�gica de pasos a cumplir por el computador 
para producir un resultadoesperado. 

La experiencia nos ha demostrado que resulta muy �til trasladar esos pasos l�gicos 
planteados en el diagrama a frases que indiquen lo mismo; es decir, hacer una 
codificaci�n del programa pero utilizando instrucciones en Espa�ol. Como si le 
estuvi�ramos hablando al computador. Esto es lo que denominaremos Algoritmo o 
Pseudoc�digo. 

Cuando logremos habilidad para desarrollar programas, es posible que no elaboremos
el diagrama de flujo; en su lugar podremos hacer directamente el pseudoc�digo 
del programa.


5.- PRUEBA DE ESCRITORIO


Para cerciorarnos de que el diagrama (y/o el pseudoc�digo) esta bien, y, para
garantizar que el programa que codifiquemos luego tambi�n funcione correctamente, 
es conveniente someterlo a una Prueba de Escritorio . Esta prueba consiste en que 
damos diferentes datos de entrada al programa y seguimos la secuencia indicada en 
el diagrama, hasta obtener los resultados. El an�lisis de estos nos indicar� si el 
diagrama esta correcto o si hay necesidad de hacer ajustes (volver al paso 4). 
Se recomienda dar diferentes datos de entrada y considerar todos los posibles casos, 
aun los de excepci�n o no esperados, para asegurarnos de que el programa no
producir� errores en ejecuci�n cuando se presenten estos casos.


6.- CODIFICACI�N 

Una vez que hayamos verificado el diagrama mediante las pruebas de escritorio, 
codificamos el programa en el lenguaje de computador seleccionado. Esto es, 
colocamos cada paso del diagrama en una instrucci�n o sentencia, utilizando un 
lenguaje que el computador reconoce. 

Todos los lenguajes de programaci�n proveen facilidades para incluir l�neas de 
comentarios en los programas. Estos comentarios aclaran lo que se ordena al 
computador y facilitan entender el programa. Puesto que estos comentarios no 
son tenidos en cuenta como instrucciones, y aparecen en los listados del programa,
 resulta muy conveniente agregar abundantes comentarios a todo programa que 
codifiquemos. Esto es lo que se denomina Documentaci�n Interna.


7.- TRANSCRIPCI�N 

El programa codificado es necesario que lo llevemos a un medio que sea aceptado 
como entrada por el computador: lo perforamos en tarjetas, lo grabamos en un disco 
flex�ble o lo grabamos en un disco duro. Este programa es el que se conoce como 
Programa Fuente (Source).


8.- COMPILACI�N 

Utilizamos ahora un programa de computador llamado Compilador o Traductor,
el c�al analiza todo el programa fuente y detecta errores de sintaxis ocasionados
por fallas en la codificaci�n o en la transcripci�n. Las fallas de l�gica que pueda 
tener nuestro programa fuente no son detectadas por el compilador. Cuando no hay 
errores graves en la compilaci�n, el compilador traduce cada instrucci�n del programa 
fuente a instrucciones propias de la m�quina (Lenguaje de Maquina), creando el 
Programa Objeto. 

Algunos computadores utilizan Interpretadores, (Generalmente para el Lenguaje Basic), 
en reemplazo de programas compiladores. La diferencia consiste en que el
interpretador recibe, desde una terminal, s�lo una instrucci�n a la vez, la analiza
y, si esta bien,la convierte al formato propio de la maquina. Si la instrucci�n
tiene alg�n error, el interpretador llama la atenci�n de la persona para que corrija
dicha instrucci�n. 

Como resultado de la corrida del compilador, podemos obtener varios listados: 

Listado del programa fuente 
Listado de los errores detectados 
Listado de campos utilizados, etc. 
Los errores los debemos corregir sobre el mismo programa fuente, ya sea reemplazando 
las tarjetas mal perforadas o regrabando en el disco flex�ble o en el disco duro. 
Este paso de la compilaci�n lo repetimos hasta eliminar todos los errores y obtener
el programa ejecutable.

9.- PRUEBAS DE COMPUTADOR 

Cuando tenemos el programa ejecutable (en lenguaje de maquina), ordenamos al
computador que lo ejecute, para lo c�al suministramos datos de prueba, como lo
hicimos en la prueba de escritorio (paso 5). Los resultados obtenidos los 
analizamos, luego de lo c�al puede ocurrir cualquiera de estas situaciones: 

a.- La l�gica del programa esta bien, pero hay errores sencillos, los cuales los 
corregimos modificando algunas instrucciones o incluyendo unas nuevas; el proceso 
debemos repetirlo desde el paso 6 . 

b.- Hay errores ocasionados por fallas en la l�gica, lo que nos obliga a regresar
a los pasos 4 y 5 para revisi�n y modificaci�n del diagrama. 

c.- Hay errores muy graves y lo m�s aconsejable es que regresemos al paso 2 para 
analizar nuevamente el problema, y repetir todo el proceso. 

d.- No hay errores y los resultados son los esperados. En este caso, el programa lo 
podemos guardar permanentemente en una librer�a o biblioteca del computador, para 
sacarlo de all� cuando necesitemos ejecutarlo nuevamente.


10.- DOCUMENTACI�N EXTERNA 

Cuando el programa ya se tiene listo para ejecutar, es conveniente que hagamos su 
documentaci�n externa siguiendo las normas de la instalaci�n o las recomendaciones 
indicadas por el profesor. Una buena documentaci�n incluye siempre: 

Enunciado del problema 
Diagrama de pasada 
Narrativo con la descripci�n de la soluci�n 
Relaci�n de las variables o campos utilizados en el programa, cada uno con su
respectiva funci�n 
Diagrama del programa 
Listado de la �ltima compilaci�n 
Resultados de la ejecuci�n del programa.