El proceso de desarrollo - Parte 1

José Dev está escribiendo un programa para automatizar algunas tareas de administración de su sistema operativo predilecto. Está entusiasmado porque desde hace algunos meses estudia programación de computadoras y sus conocimientos han llegado al nivel en el que puede aplicarlos para simplificar algunas tareas rutinarias que realiza en su ordenador.

Para resolver un problema, abre su IDE favorito y comienza a escribir algunas rutinas de código a medida que piensa en el problema que desea resolver. A veces se da cuenta que el código que está escribiendo no hace lo que realmente necesita. Entonces se toma tiempo y piensa cómo debería modificar ese código para que le resulte útil, otras veces borra aquello que no le sirve y empieza nuevamente.

En ocasiones José se queda detenido frente al ordenador sin saber muy bien qué debería hacer a continuación.

Básicamente, lo que José hace es ensayo de prueba y error: codifica toda idea que se le viene a la cabeza; si el código no hace lo que suponía que haría intenta corregirlo; si se da cuenta que en realidad es otra cosa lo que debería hacer intenta transformar ese código, y si no puede hacerlo, lo descarta y luego recomienza el ciclo.

Resulta evidente que no invierte tiempo en analizar adecuadamente el problema que intenta resolver y que no tiene una estrategia definida para abordarlo. Tampoco dedica tiempo alguno a diseñar su programa. De hecho José no entiende muy bien qué significa analizar y diseñar.

Seguir un proceso de prueba y error implica que el programador se encuentre, frecuentemente, desconcertado porque su código no funciona, no hace lo que él quiere o sencillamente no tiene idea de qué debería hacer a continuación.

Ésta es la "metodología" de programación anterior a toda las metodologías y su aplicación conduce generalmente a que el programa así escrito tenga un alto grado de entropía: el código es muy desordenado, no refleja ideas claras y difícilmente lleva a la solución buscada, o bien dicha solución se alcanza luego de un esfuerzo de programación increíblemente grande. Además, generalmente el código resultante es difícil de entender e inflexible y por lo tanto complicado de corregir, ampliar o mejorar.

Un amigo le recomendó a José que escribiera su programa utilizando pseudocódigo antes de codificarlo en su lenguaje de programación habitual. José así lo hizo, e incluso comenzó a dibujar diagramas de flujo de las rutinas que escribía. En realidad, el proceso que seguía consistía en dibujar primero el diagrama, traducirlo a pseudocódigo y finalmente codificarlo en su lenguaje de programación.

Pronto se dio cuenta que al comenzar los diagramas frecuentemente se quedaba atónito sin saber realmente qué hacer. Además, le resultaba bastante tedioso dibujarlo, escribir el pseudo-código y finalmente codificar. Se daba cuenta que sus programas resultaban más efectivos que antes, es decir que este proceso le ayudaba a escribir programas que realmente hicieran lo que él quería, pero el esfuerzo que invertía en ello era aproximadamente tres veces el que le demandaba antes.

Luego de utilizar estas herramientas en varias ocasiones, José no estaba satisfecho con los resultados y se preguntaba si, en realidad, no estaría utilizándolas de forma incorrecta. Sin embargo, intuía que le faltaba alguna herramienta que le ayudara al comienzo, es decir, justo cuando no tenía una idea clara de lo que debía hacer para solucionar el problema.

También percibía que el tiempo total de desarrollo era demasiado y ansiaba encontrar formas de escribir los programas más eficazmente.

El éxito relativo que obtuvo de la utilización de diagramas de flujo y pseudocódigo, como pasos previos a la codificación, fue el resultado de permanecer más tiempo pensando en el problema, es decir que el beneficio no provenía del uso de esas herramientas sino de su propia capacidad de análisis e inventiva. Sin embargo, el esfuerzo fue mucho mayor.

Un día, mientras leía artículos en Internet, se enteró de que los programas importantes se escribían siguiendo una serie de etapas denominadas: Análisis, Diseño, Codificación, Prueba y Depuración, Implantación y Mantenimiento. Pero no tenía idea sobre qué le proponía hacer el proceso en cascada en esas etapas, excepto en la de codificación.

José tuvo que leer varios artículos, tutoriales e incluso un manual para obtener un panorama completo. Pero lo que aprendió no le cayó en gracia. Se suponía que debía escribir varios documentos, comenzando por descripciones de lo que el programa debía hacer y sobre el que debía realizar varios refinamientos para que los requisitos quedaran expresados de una forma inequívoca y con el suficiente nivel de detalle. Luego tendría que escribir un documento de especificaciones (también llamado de requisitos o de especificación de requisitos) que detallara de forma precisa cada cosa que el programa debería hacer.

Luego, debía encontrar requerimientos que estuvieran relacionados y dibujar algunos diagramas que le permitirían visualizar cómo podría modularizar el programa para cumplir con esos requisitos. También tendría que escribir un documento que detallara las decisiones de diseño (cómo dividiría el sistema en componentes, paquetes o módulos, qué algoritmos conocidos utilizaría, qué bibliotecas, etc). Finalmente debería continuar con su proceso habitual de trabajo hasta llegar a la etapa de prueba y depuración.

En la etapa de pruebas debería diseñar y documentar exhaustivamente cada caso de prueba, ejecutarlo, y si la prueba arrojaba como resultado la presencia de un error, corregirlo y ejecutarla otra vez.

Rápidamente José se vió frustado (nuevamente) porque no era capaz de definir de una sola vez los requisitos de sus programas. En esta etapa de su aprendizaje José necesitaba escribir programas más complejos y aunque inicialmente podía volcar en un papel sus ideas sobre lo que el programa debería hacer, no era capaz de tener en cuenta todos los requerimientos y menos aún, se sentía capaz de dibujar desde el principio un esquema que definiera completamente la modularización del programa.

Cuando intentó aplicar el proceso también observó que al comenzar la etapa de pruebas encontraba fallos "tontos" que, o nunca debería haber cometido, o debería haber detectado antes.

José está utilizando el proceso de desarrollo en cascada que básicamente ignora la complejidad del desarrollo de software y por lo tanto propone etapas de desarrollo como compartimientos estancos: sólo se puede avanzar a la siguiente etapa cuando la primera esté debidamente concluida.

La métafora de la cascada sugiere el agua fluye únicamente cuando es capaz de desbordar esos compartimientos estancos, es decir que el proceso únicamente contempla un único sentido de comunicación entre las diferentes etapas (el sentido en el que el agua fluye) y que sólo es posible comenzar una etapa cuando se completó la anterior (el agua sólo puede fluir cuando llena completamente un compartimento).

Las dificultades que este planteamiento le supone han hecho que José avanzara en las etapas sin haber concluido la anterior y cuando lo necesitara volviera atrás para completar los documentos y diagramas que el proceso exige.

José no está conforme con esta forma de trabajo pero intenta seguir al pie de la letra una frase que leyó en algún sitio web "lo que no está documentado no existe" y tiene muy en cuenta otra que reza "un error que no se descubre y corrige en etapas tempranas del desarrollo tiene un costo que aumenta en forma exponencial en las etapas posteriores".

Además, intuye que comenzar a probar seriamente el programa sólo después de haberlo codificado completamente no es una buena idea; piensa que si dedicara un poco más de esfuerzo podría evitar cometer muchos errores, pero siempre se siente apurado debido a la gran carga de trabajo que el proceso le impone.

José no está aplicando el proceso al pie de la letra, sencillamente porque no es posible debido a la complejidad del problema. Probablemente, para casos mucho más simples le hubiese resultado satisfactoria esta forma de trabajo, pero en el caso actual le provoca diversos problemas. En primer lugar, encuentra que no puede aplicar el proceso tal como fue definido y esto le genera dudas respecto de su propia capacidad como programador. En segundo lugar, tiene serias dudas sobre la utilidad de los documentos que intenta mantener actualizados a medida que avanza en el desarrollo de su programa. En tercer lugar, se da cuenta que el esfuerzo que le demanda es enorme.

A medida que comenzó a utilizar herramientas conceptuales que antes no conocía José tuvo que invertir más tiempo y esfuerzo para desarrollar sus programas. Obtuvo ciertos resultados positivos, pero también obtuvo nuevos problemas que le provocan una carga de trabajo demasiado alta.

José adquirió la sana costumbre de leer artículos técnicos, manuales y hasta libros sobre desarrollo. Así fue como se enteró que estos padecimientos los tenían todos los desarrolladores del mundo y que existían herramientas que proponían solucionarlos. Comenzó a leer sobre algo llamado proceso iterativo que propone algo parecido a lo que él intuitivamente intentaba hacer al saltar hacia adelante y hacia atrás a través de las etapas cuando lo necesitaba.

Sus lecturas sobre el proceso iterativo le ayudaron a comprender que el proceso en cascada tenía serios defectos, por ejemplo, que no lo ayudaba a manejar la complejidad de las tareas a realizar.

Anterior

Siguiente