QU ES METODOLOGA DE LA PROGRAMACIN?

Conocer un lenguaje de programacin no significa tener la capacidad de desarrollar

una aplicacin compleja usando dicho lenguaje. Para depurar el estilo de
programacin es necesario seguir una metodologa segn la cual el programador
pueda crear el cdigo ptimo, independientemente del lenguaje que utilice y de la
plataforma donde lo vaya a desarrollar.
Una metodologa marca las forma de realizar todas las fases de creacin de un
proyecto informtico; en especial las relacionadas con el anlisis y diseo. Las
metodologas marcan los siguientes elementos:
Pasos exactos a realizar en la creacin de la aplicacin. Se indica de forma exacta
qu fases y en qu momento se realiza cada una.
Protocolo. Normas y reglas a seguir escrupulosamente en la realizacin de la
documentacin y comunicacin en cada fase.
Recursos humanos. Personas encargadas de cada fase y responsables de las
mismas.
Tanta importancia para una empresa tiene el hecho de seguir una metodologa, que
algunas de las metodologas son de pago. La ingeniera del software es la ciencia que
se ha encargado de desarrollar metodologas de trabajo.









LAS FASES DE LA PROGRAMACION
Las fases de programacin son:

-Anlisis
-Diseo
-Codificacin
-Compilacin
-Validacin
-Depuracin
-Mantenimiento
-Documentacin

Aunque el proceso de crear software es esencialmente un proceso creativo, el seguir
esta serie de pasos lgicos conduce a la obtencin de programas de mayor calidad.
Es muy comn que los principiantes se salten algunos pasos de esta metodologa por
desconocimiento o pereza, y procedan directo a la codificacin de los programas. Esta
prctica no slo es incorrecta, sino que hace perder tiempo, dinero y esfuerzo. An los
programadores experimentados y los profesionales utilizan esta metodologa en el
desarrollo de sus programas. Los resultados que se obtienen con su aplicacin son
ms confiables, rpidos y seguros que los obtenidos mediante prcticas incorrectas y
desordenadas.





ANLISIS

Al programar aplicaciones siempre se debe realizar un anlisis. El anlisis estudia los
requisitos que ha de cumplir la aplicacin. El resultado del anlisis es una hoja de
requerimientos en la que aparecen las necesidades a cubrir por la aplicacin. La
habilidad para obtener correctamente la informacin necesaria de esta fase la realizan
los/as analistas. La fase se cumple tras ser aprobada por el o la responsable del
proyecto (normalmente un jefe o jefa de proyecto).El anlisis se suele dividir en estas
subfases:
1. Estudio preliminar. En el que se estudia la viabilidad del proyecto. Parte de
una informacin general (la indicada por el cliente inicialmente). En ella se
estiman los recursos (tanto humanos como materiales) necesarios y los costes.
2. Obtencin de informacin. Una vez aprobado el estudio preliminar, los y las
analistas realizan entrevistas a los futuros usuarios para recabar la informacin
imprescindible para realizar el proyecto.
3. Definicin del problema. Las entrevistas dan lugar a un primer estudio
detallado del problema en el que se afina ms el estudio preliminar a fin de
determinar ms exactamente los recursos y costes necesarios y las fases que
se necesitarn.
4. Determinacin de los requerimientos. Se estudian los requerimientos dela
aplicacin a partir de los datos obtenidos de las fases anteriores.
5. Redaccin de las hojas de requerimientos. Se redactan las hojas de
requerimientos en base al protocolo a utilizar.
6. Aprobacin de las hojas. Los jefes y jefas de proyecto se encargan de revisar
y aprobar las hojas, a fin de proceder con las siguientes fases. En caso de no
aprobar, habr que corregir los errores o volver a alguna de las fases
anteriores.
7. Seleccin y aprobacin del modelo funcional. O lo que es lo mismo,
seleccin del modelo a utilizar en la fase de diseo. Se elegir el idneo en
base al problema concreto que tengamos. Como se coment en el punto
anterior, es habitual (y desde luego muy recomendable) el uso de prototipos.
En esta fase bastara con revisar los requerimientos con el usuario antes de
aprobar las hojas de requerimientos.
DISEO

En esta fase se crean esquemas que simbolizan a la aplicacin. Estos esquemas los
elaboran analistas. Gracias a estos esquemas se facilita la implementacin dela
aplicacin. Estos esquemas en definitiva se convierten en la documentacin
fundamental para plasmar en papel lo que el programador debe hacer.

En estos esquemas se pueden simbolizar: la organizacin de los datos de la
aplicacin, el orden de los procesos que tiene que realizar la aplicacin, la estructura
fsica (en cuanto a archivos y carpetas) que utilizar la aplicacin, etc. Cuanto ms
potentes sean los esquemas utilizados (que dependern del modelo funcional
utilizado), ms mecnica y fcil ser la fase de implementacin. La creacin de estos
esquemas se puede hacer en papel (raramente), o utilizar una herramienta CASE
para hacerlo. Las herramientas CASE (Computer Aided Software Engineering
Ingeniera de Software Asistida por Ordenador) son herramientas software pensadas
para facilitar la realizacin de la fase de diseo en la creacin de una aplicacin. Con
ellas se realizan todos los esquemas necesarios en la fase de diseo e incluso son
capaces de escribir el cdigo equivalente al esquema diseado. En el caso de la
creacin de algoritmos, conviene en esta fase usar el llamado diseo descendente.
Mediante este diseo el problema se divide en mdulos, que, a su vez, se vuelven a
dividir a fin de solucionar problemas ms concretos. Al diseo descendente se le llama
tambin top-down. Gracias a esta tcnica un problema complicado se divide en
pequeos problemas que son ms fcilmente solucionables. Es el caso de las
metodologas de Warnier y la de Jackson. Hoy en da en esta fase se suelen utilizar
modelos orientados a objetos como la metodologa OMT o las basadas en UML.
Durante el diseo se suelen realizar estas fases:

1. Elaborar el modelo funcional. Se trata de disear el conjunto de esquemas que
representan el funcionamiento de la aplicacin.

2. Elaborar el modelo de datos. Se disean los esquemas que representan la
organizacin de los datos. Pueden ser esquemas puros de datos (sin incluir las
operaciones a realizar sobre los datos) o bien esquemas de objetos (que
incluyen datos y operaciones).


3. Creacin del prototipo del sistema. Creacin de un prototipo que simbolice de
la forma ms exacta posible la aplicacin final. A veces incluso en esta fase se
realiza ms de un prototipo en diferentes fases del diseo. Los ltimos sern
cada vez ms parecidos a la aplicacin final.

4. Aprobacin del sistema propuesto. Antes de pasar a la implementacin del
sistema, se debe aprobar la fase de diseo (como ocurri con la de anlisis).



CODIFICACIN



En este paso se traduce el algoritmo ya estructurado, verificado y comprobado a
mano, al lenguaje de programacin que vaya a utilizarse. Slo se convierten las
acciones del algoritmo en instrucciones de computadora usando la sintaxis de un
lenguaje particular, pero requiere de conocimientos del lenguaje y de sumo cuidado en
la colocacin de las instrucciones, las que deben apegarse y seguir fielmente a la
lgica del algoritmo y la semntica y sintaxis del lenguaje.


La digitacin, el acto de teclear el algoritmo codificado, se lleva a cabo para
almacenar el programa en la memoria de la computadora (virtual o fsica) y pueda ser
aceptado por esta. Con frecuencia los programadores realizan la codificacin y la
digitacin al mismo tiempo a fin de ahorrar tiempo, pero esto puede conducir a errores
debido a la prdida de concentracin que implica el uso de un editor.



COMPILACIN







La compilacin, o correccin de los errores sintcticos y semnticos del cdigo, es la
eliminacin de los errores "gramaticales" segn las reglas de construccin de
instrucciones particulares del propio lenguaje (la sintaxis). Puede hacerse a medida
que se traduce, pero es mejor al final para no perder la secuencia de la codificacin.
Al terminar debe tenerse el cdigo libre de los errores antes mencionados.

Para realizar la compilacin puede hacerse uso de un compilador, el cual es un
programa especial que analiza todo el cdigo fuente y detecta los errores antes
mencionados ocasionados durante la codificacin o la digitacin. Las fallas de lgica
que puedan existir en nuestro programa no son detectadas por este software. Los
errores que s son evidenciados por el compilador deben corregirse modificando el
programa fuente.
VALIDACIN

En esta tercera fase de validacin de la
evaluacin especficamente se pretende
responder a la cuestin bsica de si el
programa rene las condiciones para poder ser
evaluado. Si con la superacin del control de la
fase anterior podemos afirmar que lo que
tenemos entre las manos es realmente un
programa porque responde a la estructura formal de lo que se considera como tal -y
no es una mera serie de actividades ms o menos secuenciadas o un cmulo de
buenas intenciones o una pequea intervencin- y es adecuado y aceptable al
contexto, necesidades y subsistemas a los que se dirige e implica. En esta fase se
pretende comprobar que los elementos formales estn diseados de tal forma que
pueden ser evaluados, que renen los requisitos mnimos para que puedan pasar
aceptablemente los criterios, valoraciones, diseos y anlisis propios de la evaluacin
de programas, si merece la pena los costes y esfuerzos de la misma, e incluso los
aspectos en que se debe centrar la evaluacin.

Las dimensiones propias de esta fase no quedan determinadas ni concretadas si no
se establecen una serie de criterios de validacin de evaluacin; as, Berk y Rossi
(1990) estiman que un programa no es evaluable si:
1. Sus objetivos no estn claramente especificados.
2. No est definida la estructura y componentes de forma adecuada.
3. No se pueden predecir con un mnimo de rigor las consecuencias de su no
aplicacin.
4. No se conocen los recursos reales disponibles para implantarlo.

En funcin de estos criterios sugerimos que, al menos, deberan seguirse los
siguientes para la validacin de un programa de orientacin, que no podr ser
evaluado si:
5. Sus objetivos no estn formulados de forma operativa/conductual (si no son
medibles y observables).
6. Las actividades planificadas no son suficientes para la consecucin de los
objetivos planteados.
7. No tiene delimitadas las acciones o actividades a realizar en unas coordenadas
espacio/temporales.
8. No se conocen los recursos materiales y humanos disponibles para implantar
el programa.
9. Existen graves obstculos y/o contingencias previsibles que imposibiliten la
ejecucin de la evaluacin.
10. No existen en el programa procedimientos para la recogida de informacin de
los datos de evaluacin o son de muy baja calidad.
11. Los datos previstos son de muy baja calidad.
12. El coste previsto (esfuerzo, tiempo, recursos materiales) es superior a la
utilidad y/o ventajas de la misma

Para que un programa sea evaluable ha de cumplir la mayora de estos criterios
(aunque no necesariamente todos) y en un nivel aceptable de cumplimiento. Ante la
inexistencia de una normativa especfica en este sentido, es el propio evaluador como
experto, y a la luz de los supuestos previos que dirigen la evaluacin (objetivos,
destinatarios, utilidad...), el que debe fijar ambos aspectos: qu aspectos considera
prioritarios en la validacin del programa y qu nivel debe exigirse en el cumplimiento
(logro) de los mismos.


DEPURACIN


Una vez compilado el programa, este es sometido a pruebas a fin de determinar si
resuelve o no el problema planteado en forma satisfactoria. Para ello le suministramos
datos de prueba, como lo hicimos en la prueba de escritorio. El programa codificado y
compilado no garantiza que funcione correctamente. Debe depurarse (librarse de
errores de lgica o de ejecucin) realizando corridas de prueba continuas con datos y
respuestas conocidas como lo hicimos en la prueba de escritorio, verificando todas las
posibles alternativas del programa y sus respuestas y haciendo el mayor nmero de
variantes con sus combinaciones, a fin de determinar si resuelve o no el problema
planteado en forma satisfactoria.

Las pruebas que se aplican al programa son de diversa ndole y generalmente
dependen del tipo de problema que se est resolviendo. Comnmente se inicia la
prueba de un programa introduciendo datos vlidos, invlidos e incongruentes y
observando cmo reacciona en cada ocasin.




Los resultados obtenidos en las pruebas pueden ser cualquiera de los siguientes:

a. La lgica del programa esta bien, pero hay errores sencillos, los cuales los
corregimos eliminando o modificando algunas instrucciones o incluyendo
nuevas.
b. Hay errores ocasionados por fallas en la lgica, lo que nos obliga a regresar a
las fases de Diseo y Codificacin para revisin y modificacin del diagrama.
c. Hay errores muy graves y lo ms aconsejable es que regresemos a la fase
2 para analizar nuevamente el problema, y repetir todo el proceso.
d. No hay errores y los resultados son los esperados. En este caso guardamos el
programa permanentemente en un medio de almacenamiento.
Puede ser necesario en la mayora de los casos retroceder a fases previas de
desarrollo, revisar el algoritmo otra vez en caso de errores de anlisis y/o lgica (que
son los ms difciles de detectar, a diferencia de los de sintaxis y semntica), realizar
ajustes al cdigo y una serie de nuevas ejecuciones de prueba para que el programa
funcione correctamente. Si no existen errores en el programa, puede entenderse la
depuracin como una etapa de refinamiento en la que se ajustan detalles para
optimizar el desempeo del programa.

Si se est automatizando alguna tarea manual, es comn poner a funcionar por un
tiempo y de forma paralela ambas alternativas, a fin de comparar las salidas de ambas
y adquirir confianza en la solucin automatizada.

MANTENIMIENTO

Es posible que el programa deba revisarse
cada cierto tiempo para ajustes. Estos
cambios pueden ser por la dinmica del
problema, por la naturaleza del cdigo, las
exigencias del tiempo o las modernas
necesidades que surgen frecuentemente, por
lo que se considera que ningn programa es
esttico. Los programas siempre son susceptibles de mejoras y de mantenimiento.
Por tales razones, es comn que se tenga que retornar a una de las fases iniciales de
desarrollo para corregir o aadir funcionalidades, repitiendo el proceso en cada fase
subsiguiente para introducir los cambios pertinentes y lograr que el programa funcione
correctamente con los cambios realizados. Se enfatiza el hecho de que cualquier
actualizacin o cambio en el programa deber reflejarse en su documentacin para
que sta mantenga su vigencia.


DOCUMENTACIN


Es la fase ms ignorada por la mayora de los programadores noveles, por razones de
tiempo, costos o simple pereza. Pero no documentar los programas es un mal hbito
en programacin y un gran error. Ser muy difcil a los usuarios entender un programa
si no cuentan con un manual de operaciones (el Manual de Usuario). Tambin para
los programadores que necesiten darle mantenimiento o hacerle modificaciones si no
existe ninguna documentacin acerca de sus fases de desarrollo. Incluso ser difcil
de entender para el mismo autor, algn tiempo despus.

La documentacin es la gua o comunicacin escrita en sus variadas formas, ya sea
en enunciados, procedimientos, dibujos o diagramas y sirve para ayudar a
comprender o usar un programa o para facilitar futuras modificaciones
(mantenimiento). Recoge todos los elementos encontrados y material creado en las
diferentes fases del desarrollo, adems de las normas de instalacin o las
recomendaciones para la ejecucin del programa.

La documentacin se divide en tres partes:
Documentacin Interna
Documentacin Externa
Manual del Usuario
Documentacin Interna: Son los comentarios que se aaden al cdigo fuente para
clarificarlo.

Documentacin Externa: Es todo el material creado y empleado en las diferentes
fases del desarrollo del programa. Incluye:
Descripcin del Problema
Narrativo con la descripcin de la solucin
Autor(s)
Algoritmo (diagrama de flujo y/o pseudocdigo)
Cdigo Fuente (programa)
Relacin de los elementos utilizados en el programa, cada uno con su
respectiva funcin
Limitaciones del programa
Manual del Usuario: Describe paso a paso la manera como funciona el programa,
con el fin de que los usuarios pueda operarlo correctamente y obtener los resultados
deseados.