Hace muchos años atrás tome la decisión de desarrollar una aplicación, de inventario (para variar un poco), fue la primera vez que me proponía iniciar algo grande y quería que todo saliera a la perfección. Me documente en lo que pude, programación, planificación, herramientas, técnicas, etc. Aprendí a utilizar UML para complementarme con programación estilo OOP (Object Oriented Programming). Empecé diseñando esquemas, gráficas, también realice historias (Use Cases) y todo lo habido y por haber. Intentaba y al tiempo las cosas no deslumbraban, y decidía empezar de nuevo. Me di cuenta que ya habían pasado casi 3 meses en análisis y diseño. Decidí continuar hasta terminar todos los posibles escenarios. Luego empecé a codificar solo para darme cuenta que muchas cosas que había creído que iban a funcionar en realidad no tenían nada que ver con lo que estaba programando. Esto es concretamente “Desarrollo en Cascada” y conlleva la mayoría (sino es que todas) de veces a un parálisis de análisis.

La contra parte es empezar un proyecto sin ninguna planificación, directamente al teclado, cosa que también hice al principio de mi carrera… y me fue muy mal. ¿Y entonces por donde comenzamos? Se debe buscar un equilibrio, tener el conocimiento suficiente del problema pero tampoco demorar mucho en empezar a codificar. Técnicas de metodología de Desarrollo Ágil (Agil Development), como Extreme Programming o Scrum por ejemplo, promueven, en esencia, este estilo de desarrollo, aun mas importante, se basan en el desarrollo “Iterativo” que es básicamente un equilibrio en lo que se viene mencionando. Por ejemplo, en la iteración 1, se planifica poco y se codifica otro poco, se obtiene algo tangible. Iteración 2, se planifica un poco mas y se codifica. Y así sucesivamente. Lo primordial en cada iteración es lograr algo que funcione o que “corra”, no va ser elegante, ni sera eficiente, y sera solo una pequeña parte de la aplicación, pero es vital que se logre. Luego, en la siguiente iteración, como ya se tiene una idea mas clara de como encajan las cosas y seguramente se habrán descubierto cosas imprevistas en el camino, esta ya no sera tan impredecible como la anterior.

Hay algo importante que destacar sobre este proceso, y es lo que lo hace muy distinto de esta “ingeniería” a las demás, y es que el crecimiento de la aplicación es mas orgánica que lineal. Con esto me refiero a que, como a un árbol, no podemos controlar de que forma crecerá, que dirección tomaran sus ramas, pero si podemos podarlo y conforme vaya creciendo le vamos dando forma hasta lograr la forma que queremos. En un proceso lineal (o cascada), como construir un edificio, debemos crear los planos primero, saber exactamente por donde pasaran las tuberías, los conductos, las gradas, el ascensor, etc. y saber sus dimensiones. No es hasta tener los planos que se empieza la construcción y conforme se levanta el edificio no hay vuelta atrás. En software no tenemos esto, trabajamos con un modelo mental, las estructuras solo son visibles en nuestra cabeza, es extremadamente difícil hacer un plano preciso desde el principio, esto se debe a que no podemos predecir que problemas surgirán en el camino. Con el desarrollo iterativo, vamos descubriendo terreno poco a poco.

Cabe mencionar que algunas las técnicas y herramientas que complementan estas metodologías, como UML, su uso ideal es para esclarecer y entender el problema que se esta tratando. Es redundante tratar de “codificar” la aplicación haciendo uso de esquemas e historias. La única forma de resolver el problema programando es pues, programando. Razón de esto es porque la realidad del problema que se percibe durante el análisis es otra a la que se percibe cuando se codifica. Con estilo OOP por ejemplo, surgen jerarquías de objetos que no tiene presentación en la vida real, su uso es exclusivamente técnico, como la conexión a una base de datos, y estas suelen salir a luz hasta la codificación.

Dicho todo esto, a lo que se aspira es un equilibrio entre no paralizarse en el análisis ni tampoco empezar a codificar sin tener claro lo que se debe de hacer. Lo aconsejable es iterar.

No Comments so far.

Leave a Reply

No dudes en dejarnos tus comentarios y si conoces algun otro tema sobre el quisieras que publiquemos, nos puedes contar.