Skip to content

Chocolate

Éste es un ejemplo de cómo funciona un desarrollo «clásico». Todavía no he podido profundizar en los métodos «agile» lo suficiente para saber hasta qué punto es mejorable.
Digamos que funciona, y que para poder dar una visión de los distintos roles que un desarrollador puede ejercer nos servirá.

La necesidad, o los requerimientos
Una mañana llega el usuario y dice «tengo hambre».

error: cualquier «paso documentado» de un proyecto debe ser breve, però conciso. «Tengo hambre», «quiero comer» y frases como ésta sólo pueden conducir al desastre. Por ejemplo: el analista pide una herramienta que permita llevar comida al usuario. EL resto del proceso continúa hasta que se pone en marcha la herramienta. Es un robot que sale de casa del usuario, busca un restaurante, pide un menú de tres platos y se lo lleva al usuario. Éste dice «yo sólo quería matar el gusanillo, no necesito tres platos de restaurante, que además se me va del presupuesto».

El Análisis (antiguamente «análisis funcional»)
Cuando empieza un proyecto, la tarea del analista es determinar de una forma suficientemente clara y concreta las necesidades del usuario. En este caso, empieza el proceso con una serie de preguntas del tipo «¿mucha o poca?», «¿dulce o salado?», «¿caro o barato?». De este intercambio de información sale el análisis: «necesitamos chocolate».

El diseño (antiguamente «análisis orgánico»)
Partiendo del análisis, el diseñador construye sobre el papel una colección de elementos que permiten llegar al objetivo. Un buen diseño conduce a un producto eficiente y eficaz (de consumo reducido, fácil de mantener, etc): «baja a la tienda y trae chocolate».

El programa (antiguamente «programa»)
Es el resultado final, eso tan esperado que permitirá al usuario satisfacer su necesidad.

Las pruebas
Debemos asegurarnos de que el programa satisfará las necesidades del cliente, y que lo hará de la forma más eficaz posible. Para eso se llevan a cabo (un número indeterminado de veces en función de la organización del proyecto, su metodología o tamaño) las pruebas.

En un mundo ideal, las primeras pruebas se realizan con la ayuda de lo que se podría denominar «juego de pruebas»: un conjunto básico de datos e instrucciones que permiten al programador verificar que el programa satisface, o parece satisfacer, las necesidades del usuario. Si el juego de pruebas especifica «tiene que traer chocolate» y la herramienta trae plátanos, el programador debe revisar y arreglar (o rehacer) lo que sea necesario hasta que la herramienta proporcione chocolate.
Una vez realizadas estas primeras pruebas, el equipo realiza una serie más exhaustiva, forzando la herramienta de tal forma que qualquier punto flaco aparezca y se pueda arreglar. Puede ser que la herramienta haya traído chocolate porque ha sido lo primero que ha encontrado, y si cambiamos algún parámetro (la distribución de la tiend, por ejemplo), quizá el programa en vez de buscar chocolate traiga lo primero que encuentra, que son tomates.

El ciclo de desarrollo
Durante toda mi vida como desarrollador, y cuando he tenido suerte, el proceso de construcción de las herramientas ha sido más o menos éste, y siempre enfocando los esfuerzos en producir y entregar la totalidad del proyecto de una tacada. Pero no tiene por qué ser así. Se puede dividir el desarrollo en partes más pequeñas, y repetir el proceso para cada una de ellas, e incluso ciclar cada parte: se realizan las pruebas, el usuario lo revisa y sugiere/pide cambios y/o mejoras, y se repite. Tantas veces como sea necesario (o como permitan tiempo y presupuesto) para tantas partes como definamos, hasta tener la herramienta más completa posble.

Un proyecto debería ser aproximadamente un 90% de papel contra un 10% de código. PERO entiéndase por papel «diseño» y no «documentación». Ya hablaremos de ello en otro momento.

Primary Sidebar