Fase de 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. 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. Prueba y Depuracin (Puesta a Punto o Testing): 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 est 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.

Plan de Pruebas Un plan de pruebas est constituido por un conjunto de pruebas. Cada prueba debe

dejar claro qu tipo de propiedades se quieren probar (correccin, dejar claro cmo se mide el resultado especificar en qu consiste la prueba (hasta el ltimo detalle de cmo se definir cual es el resultado que se espera (identificacin, tolerancia, ...)

robustez, fiabilidad, amigabilidad, ...)

ejecuta)

Cmo se decide que el resultado es acorde con lo esperado? Las pruebas angelicales carecen de utilidad, tanto si no se sabe exactamente lo que se quiere probar, o si no est claro cmo se prueba, o si el anlisis del resultado se hace "a ojo". Estas mismas ideas se suelen agrupar diciendo que un caso de prueba consta de 3 bloques de informacin: 1. 2. 3. El propsito de la prueba Los pasos de ejecucin de la prueba El resultado que se espera

Y todos y cada uno de esos puntos debe quedar perfectamente documentado. Las pruebas de usar y tirar ms vale que se tiren directamente, an antes de usarlas.

Cubrir estos puntos es muy laborioso y, con frecuencia, tedioso, lo que hace desagradable (o al menos muy aburrida) la fase de pruebas. Es mucho mas divertido codificar que probar. Tremendo error en el que, no obstante, es fcil incurrir. Respecto al orden de pruebas, una prctica frecuente es la siguiente: 1. 2. Pasar pruebas de caja negra analizando valores lmite. Recuerde Identificar clases de equivalencia de datos (entrada y salida) y

que hay que analizar condiciones lmite de entrada y de salida. aadir ms pruebas de caja negra para contemplar valores normales (en las clases de equivalencia en que estos sean diferentes de los valores lmite; es decir, en rangos amplios de valores). 3. Aadir pruebas basadas en "presuncin de error". A partir de la experiencia y el sentido comn, se aventuran situaciones que parecen proclives a padecer defectos, y se buscan errores en esos puntos. Son pruebas del tipo "Me lo tema!" 4. Medir la cobertura de caja blanca que se ha logrado con las fases previas y aadir ms pruebas de caja blanca hasta lograr la cobertura deseada. Normalmente se busca una buena cobertura de ramas (revise los comentarios expuestos al hablar de caja blanca).

PD:
agreguen al final

busquen una imagen como ejemplo donde venga una

persona analizando un cdigo o algo que se le parezca para que la