INTRODUCCIN

Aunque pueda parecer extrao, buena parte de los quebraderos de cabeza a los que nos
enfrentamos programando derivan de no saber bien lo que queremos hacer. Esto responde al
siguiente esquema:

Este sistema es posible pero muy poco recomendable ya que equivale a:

Lo cual implica, simplemente, comenzar una tarea sin la preparacin necesaria. En el ejemplo
del edificio slo en situaciones de extrema sencillez (por ejemplo levantar un cuarto) el
resultado ser satisfactorio. En el resto de los casos la falta de mtodo llevar a defectos o
colapsos debido a la ausencia de proyecto, planos, clculos, etc.

No podemos pretender desarrollar un programa simplemente en base a ideas, intuiciones,

nociones. Necesitaremos mtodo y esquemas claros que raramente estarn en nuestra
cabeza. Necesitarn de un trabajo de desarrollo.

El buen programador, al igual que el buen proyectista en arquitectura, ha de tener claros

cules son los pasos a ir dando para desarrollar una construccin slida. La precipitacin, la
falta de reflexin o las prisas por terminar son malas consejeras.

Cada programador tiene sus propios esquemas de trabajo, pero en lneas generales podemos
distinguir las siguientes fases en el desarrollo de un programa:
CONOCER EL PROBLEMA A RESOLVER

Como primer paso a la hora de desarrollar un programa tenemos "conocer el problema a

resolver". Necesitaremos un conocimiento profundo de todos los aspectos relacionados con el
problema, lo cual implica saber responder las siguientes preguntas:

1. Cul es mi objetivo?
2. Cules son los condicionantes que afectan al problema?
3. Qu mtodo o esquema de resolucin voy a aplicar?
4. Cules son los datos de partida?
5. Qu resultado quiero obtener?

SOBRE EL OBJETIVO

A la hora de plantear un objetivo trataremos de subdividir la extensin y complejidad del

problema hasta niveles lo ms fcilmente abarcables por una persona, segn la conocida
estrategia del "divide y vencers".

Aunque ser la experiencia la que mejor nos gue a la hora de plantear objetivos podemos
usar esta regla: "Slo trataremos de programar aquello que mentalmente somos capaces de
abarcar en mtodo, extensin y condicionantes".

Ejemplo: Supongamos que trabajamos en el sector de logstica y almacenamiento de

combustibles y venimos haciendo diversos clculos manuales relativos a determinacin de
volmenes de depsitos. Por cambios productivos se empiezan a instalar depsitos de formas
geomtricas muy diversas y decidimos programar para obtener volmenes.

Posibles planteamientos de objetivos:

a) Desarrollar un programa para el clculo de volmenes para cualquier forma de depsito

contenedor de un lquido.
Comentarios: incumplimos la premisa de plantear algo que mentalmente seamos capaces
de abarcar. Lo planteado posiblemente se puede programar, pero al nivel en que nos
encontramos (somos programadores individuales y no expertos) el objetivo resultara
inalcanzable. Entre otras cosas por la gran cantidad de formas regulares (esferas, elipsoides,
pirmides, conos, cuas, paraboloides, hiperparaboloides, etc.) que en el caso de las
irregulares o combinaciones entre irregulares se tornan en infinitas posibilidades. Los datos
de partida y los mtodos resultaran de extensin y complejidad inabarcable.

Continuamos con otro posible planteamiento de objetivos de programacin:

b) Desarrollar un programa para el clculo de depsitos (volmenes) de los siguientes tipos:

Esfera seccionada en su base inferior para conseguir una base plana de apoyo.
Cono circular.
Tronco de una pirmide.

Comentarios: problema que mentalmente somos capaces de abarcar con un esquema como
el mostrado en la Figura 1.

A la hora de plantear el objetivo no es imprescindible elaborar un esquema como el anterior.

Es suficiente saber hacer una valoracin global respecto a si creemos conocer los
condicionantes, mtodos y datos de partida as como si tenemos claros los resultados a
mostrar.

Por ltimo, en cuanto al objetivo, desde este momento conviene empezar a pensar en
resolver problemas genricos con variables no fijadas.

Ejemplo: Si habitualmente trabajamos con depsitos de combustible tipo esfera seccionada

con una altura eliminada de 2 metros, podramos "fijar" este parmetro de modo que dejar
de ser un dato de entrada. Esto a su vez "simplificara" el proceso de clculo al tener una
variable menos.

Sin embargo, recomendamos no hacer esto porque a la larga nos supondr adquirir un mal
hbito de programacin. Lo adecuado ser pues, programar el caso genrico de un depsito
con radio r y altura eliminada h. Si se quiere evitar que el usuario tenga que introducir un
valor que se repite (h) podemos hacer que aparezca como predeterminado en la lista de
datos de entrada, o bien que se acceda a cambiarlo a travs de una opcin especfica.

A la hora de programar nos interesa obtener la mxima potencialidad posible para el tiempo
y esfuerzo que apliquemos a la tarea. Obtener potencialidad implica que el programa sea
capaz de resolver el mayor nmero de casos y variantes posibles. Por tanto el programa hay
que "abrirlo".
 Figura 1. Esquema para un problema de clculo de volmenes.

El planteamiento de objetivos se resume en el siguiente cuadro:

Proceso Movimiento tipo Finalidad

 Hacer abarcable el objetivo subdividiendo en
Centrar Cerrar el problema
extensin y complejidad

Enfocar Abrir el problema Obtener mxima potencialidad

EJERCICIO

Distintas personas han planteado estos seis objetivos para desarrollar un programa til para
su trabajo. Hacer una valoracin de los mismos.

1. Programa para clculo de muros de contencin de tierras.

2. Programa para determinar la facturacin de un producto que se vende a 0,60 / ud para
ventas de hasta 50 unidades y a 0,55 / ud para ventas de ms de 50 unidades.
3. Programa para determinar el peso de una plancha de hierro rectangular a la que se hace
una perforacin circular.
4. Programa para simular el disparo de un proyectil que se supone sigue un tiro parablico.
5. Programa para el clculo de edificios de hasta 8 plantas.
6. Programa para el clculo de armaduras de muros de hormign armado con puntera y
taln.

SOLUCIN

1. Planteamiento no suficientemente centrado. Existen diferentes tipologas de muros de

contencin, que a su vez pueden estar afectados por mltiples tipos de carga, etc. Por tanto,
problema demasiado extenso.

2. Problema bien centrado. Como nica indicacin, recomendamos programarlo partiendo

de valores variables en vez de fijos. Es decir, desarrollaremos un programa para determinar
la facturacin de un producto que se vende a x / ud para ventas de hasta n unidades y a z
/ ud para ventas de ms de n uds.

3. Problema bien centrado y bien enfocado.

4. Problema bien centrado y bien enfocado. Obviamente es ms complejo que el caso de

resolver el peso de la plancha de hierro en el que rpidamente se nos ocurren las variables y
procedimientos de clculo.

5. Problema no centrado. Si se refiere a un clculo de cimentacin, estructura,

instalaciones, etc., la cantidad de variantes y su complejidad invitan a subdividir, y mucho.

6. Planteamiento que puede ser correcto aunque al menos mentalmente deberamos acotar
a un problema concreto (p. ej. muro que soporta un relleno sin talud y sin sobrecargas). Una
vez resuelto este programa, podramos aumentar las posibilidades de clculo del mismo (p.
ej. cargas lineales, cargas en faja, etc).

SOBRE LOS CONDICIONANTES

Llamamos condicionantes a todos los factores que afectan a la resolucin del

problema. Despus de tener un objetivo centrado y enfocado tendremos que valorar qu
condicionantes nos afectan y si tenemos un conocimiento suficiente de ellos.

Podemos hacer la siguiente clasificacin:

1. Condicionantes de clculo: aquellos que afectan a la estrategia de resolucin del

problema.
Ejemplo: En un programa para calcular las prdidas de carga en tuberas, admitir o no la
presencia de accesorios (codos, vlvulas, etc).

2. Condicionantes tipo parmetro: son los referidos a materiales, dimensiones o formas

geomtricas, tiempos, etc.

Ejemplo: viscosidad de un lquido, peso especfico de un material.

3. Condicionantes bifurcadores: seran los que, en funcin de un valor introducido por el

usuario o un valor resultado intermedio llevan a distintas vas de resolucin.

Ejemplo: para el clculo de prdidas de carga en una tubera el condicionante: "se trata de
rgimen laminar?" supone la bifurcacin:

4. Condicionantes tipo restriccin:

4.1 Para admisin de datos: pueden resultar no admisibles ciertos valores para datos de
entrada, bien por motivos tcnicos, comerciales u operativos, o bien por imposibilidad fsica,
matemtica, etc.

Ejemplo: para ordenar una serie de nmeros es viable aceptar nmeros positivos o
negativos. En cambio, si pedimos la altura de un pilar no tiene sentido admitir un valor
negativo.

Si tratamos de realizar ciertos clculos relacionados con una nave industrial, podemos acotar
el rango de luz o distancias entre pilares a distancias tcnicamente viables. Podemos
preparar el programa para que detecte cualquier valor que consideremos anmalo e impida
la continuacin de procesos hasta tanto no se corrija.

4.2 Para la emisin de resultados: ciertos datos de entrada en principio viables pueden
dar lugar a resultados no admisibles.

Ejemplo: se trata de determinar el nmero de farolas necesarias por kilmetro para la

iluminacin de una avenida, siendo la dimensin de la base de la farola 40x40 cm. Si por
cualquier circunstancia el programa llegara a un valor de ms farolas de las que fsica o
razonablemente se pueden disponer, deberamos abortar la presentacin del resultado e
instar a corregir los datos de partida como potencia, altura, etc., para poder obtener un
resultado viable. Podemos preparar el programa para que detecte cualquier resultado que
pudiramos considerar anmalo, impidiendo su presentacin y mostrando un mensaje de
error o advertencia.

SOBRE EL MTODO O ESQUEMA DE RESOLUCIN

Una vez determinado el objetivo y conocidos los condicionantes, valorar el mtodo o

esquema de resolucin para el problema planteado ser el siguiente paso en el proceso de
conocer el problema. Ser una etapa ms a cumplir antes de empezar a trabajar en su
programacin.
Los mtodos aplicables son muy diversos por lo que es difcil hacer acotaciones tericas
respecto a los mismos. Haremos pues una clasificacin prctica de distintas formas o tipos de
resolucin de problemas a los que nos enfrentaremos como programadores. Un programa
extenso puede ser una mezcla de distintos tipos de problema.

Problema con resolucin directa

Se tratara de todo tipo de problemas que solucionamos mentalmente, de forma sencilla, en

uno o varios pasos. El esquema a que nos referimos sera del tipo:

El procedimiento de resolucin puede ser directo como:

O bien indirecto como:

En resumen, se tratara de programas o partes de programas en los que nicamente

utilizamos razonamientos ms o menos directos, operaciones bsicas (sumas, restas, ...)
reglas de tres, frmulas poco complejas, etc.

Ejemplo:
Puede darse el caso de problemas largos (muchos pasos a dar) pero operaciones sencillas.
Ms que la longitud, ser la existencia de mltiples bifurcaciones lo que pueda complicar la
programacin.

Problema con resolucin documentada

Se tratara de un problema con tipologa similar al anterior pero que no resolvemos

directamente sino mediante una consulta a prontuarios, manuales, libros o apuntes. El
esquema sera del tipo:

Ejemplo:
Aparte de lo dicho para el caso anterior, convendr tener cuidado con el uso de frmulas
matemticas y su escritura. Lo estudiaremos ms adelante.

LA ANCDOTA EN TORNO A CONOCER EL PROBLEMA

En cierta ocasin nos propusimos desarrollar un programa informtico que

permitiera decidir qu operador telefnico convena usar para realizar una llamada,
desde el punto de vista econmico. Como condicionantes se pens en las distintas
compaas que permitan todo tipo de llamadas, los tipos de telfonos (mvil-fijo),
los lugares de origen-destino, las tarifas y la hora de la llamada (horario reducido o
normal).

As pues, se decidi, antes de recabar todos los datos y ni siquiera de pensar en la estrategia
de resolucin, realizar un tanteo entre dos compaas a las que llamaremos Operador 1 y
Operador 2. El tanteo consisti en una comparativa en una hoja de excel que permitiera
valorar la influencia del destino de llamada, qu tipo de grficos seguan las tarifas, posibles
simplificaciones, etc. Muchas de las tablas obtenidas fueron de este tipo:

HORARIO NORMAL (8 a 20 horas, de lunes a viernes)

LLAMADAS CON OPER. 1 DE FIJO A LLAMADAS CON OPER. 2 DE
MVIL FIJO A MVIL
A oper. 1 A oper. 2 A oper. 3 A oper. 1 A oper. 2 A oper. 3
1min 50,4 50,4 55,4 45 45 45
1 min 30 67,5 67,5
69,9 69,9 77,4 67,5
s
 2 min 89,4 89,4 99,4 90 90 90
2 min 30 112,5 112,5
108,9 108,9 121,4 112,5
s
3 min 128,4 128,4 143,4 135 135 135
Nota: Coste de las llamadas en cntimos de euro.

De estas tablas se desprendan preguntas-respuestas tales como:

Pregunta: Qu operador debo usar si voy a llamar a un mvil desde un fijo hoy mircoles
en horario laboral?

Respuesta:Si la llamada dura menos de 1 min. y 30 seg. debe usar el Operador 2. Si la

llamada dura 2 min. y es a un mvil del Operador 1 2 puede usar indistintamente el
Operador 1 o el Operador 2. Si la llamada dura dos minutos y es a un mvil del Operador 3
debe usar el Operador 2. Si la llamada dura dos minutos y medio o ms y es a un mvil del
Operador 1 2 debe usar el Operador 1, pero si es a un mvil del Operador 3 debe usar el
Operador 2.

Grficamente algo as:

Del tanteo se desprenda que haba ms condicionantes de los esperados (p. ej. no bastaba
saber si se llamaba a un fijo o a un mvil sino que haba que saber a qu operador mvil se
llamaba; por otro lado, la existencia de un coste de establecimiento de llamada daba lugar a
grficas de tarifas no paralelas sino secantes...). Esto daba pie a concluir que el objetivo, tal y
como se haba planteado, era una quimera. Haba que replantearlo o cesar en el empeo.

La conclusin fue que en las compaas telefnicas cuanto menos se piense mejor, y que si
un programa nos va a complicar la vida en vez de facilitrnosla, ms vale dejarlo en el
tintero.
P. S. Recordando al clebre Y sin embargo, se mueve.... Y sin embargo, se puede
programar...