Ente el análisis y la programación

“Para su examen, evaluaré con un 50% lo que tengan en papel, el otro 50% será su aplicación”. Esa frase me la dijo una profesora en mis primeras clases de programación, no necesito contarles que reprobé el examen por no haber tenido nada coherente escrito en mi libreta. Ahora a unos años de esa clase y de ese examen me doy cuenta de que mi profesora estaba mal ¡Yo le daría un 70% al papel y un 30% a la aplicación!

No quiero decir con esto que estoy menospreciando la labor de un programador, quiero decir que la vida de un programador es muchísimo mas sencilla si supiera lo que tiene que hacer. Basta tener un buen puñado de programadores como contacto en redes sociales como para ver cuanto se quejan de lo molesto que es ver como su cliente les cambia sus requerimientos, pero hasta ahora no he visto en ninguna ocasión que hagan algo por remediarlo, solo sufrimos y esperamos que en la siguiente reunión no se le ocurra nada mas a nuestro cliente y podamos sacar una versión final. Ese es el escenario, y lo peor es que así seguimos trabajando.

La ingeniería del software no solo es sentarnos a ver que y como vamos a escribir el código de una aplicación, para eso existe la vital etapa del análisis e ignorar esta parte es colocarnos una soga en el cuello con nuestras propias manos.

Sin un buen principio no hay un buen final

No puedo concebir como sin planificar ni con una buena metodología, puede salir airosa una aplicación completamente funcional. Sé que será muy polémico si dijera “cualquiera puede programar”, así que puedo refinar la expresión diciendo “Prácticamente cualquiera puede programar una aplicación con una guía y camino que le indique que debe hacer” Esa expresión debe ser mucho mas aplicada en todos nuestros proyectos.

Cuando veo a un ingeniero civil crear una maqueta me doy cuenta de que veo una profesión que a lo largo de su vida (mucho más extensa que la del software) ha pulido un punto vital, el intermedio entre las etapas que le dan título a este artículo, la creación de un prototipo.

Cuando habla con sus clientes obtiene todo lo que necesita para crear su maqueta, no lo veo gastando millones de pesos en construcción y que a medio camino el cliente se pueda dar el lujo de decir “¿Sabes qué? No, mejor que esa curva vaya a la izquierda, se me haría mas práctico”. La maqueta determina como queda, desde ahí el cliente minimizará su participación hasta llegar al punto de ser un mero observador que solo estará al tanto del proceso de desarrollo, pero consiente de que ya no podrá modificar ningún aspecto de su producto.

¿Qué es un prototipo?

Hay que ser bien claros en la conceptualización, es mucho más común de lo que puedan creer que se pueda confundir a un prototipo con una aplicación demostrativa. Para ser mas claro, una aplicación “demo” debe ser muy vistosa, atractiva y contar con un guion que le dará la magia necesaria para encantar a nuestro cliente potencial y convencerlo de que somos los indicados para realizar su trabajo.

El prototipo por otro lado debe ser la consolidación visual de nuestra etapa de análisis plasmada de tal forma que nuestro ahora cliente note todos los alcances y navegabilidad de su futura aplicación, tampoco se trata de una aplicación finalizada, es aquí donde debe quedar claro que también debe desprenderse del concepto de una versión de prueba del producto, de hecho cubriendo las buenas prácticas de la ingeniería del software deberá llevar el mínimo de líneas de código posibles pues no es el fin de un prototipo comenzar a programar sino demostrar cabalmente lo que la aplicación podrá realizar, solo cuando nuestro cliente de el visto bueno de forma completa a nuestro prototipo es que puede comenzar el proceso de desarrollo del producto.

Ahora es en donde se podrá notar la razón de mi frase inicial, el camino ha sido delimitado de una forma tan clara que para el programador no debe existir duda alguna de lo que debe hacer, pues tiene la guía exacta de lo que realizará y un boceto muy importante de como se verá (el prototipo no debe considerar la interfaz final del producto sino únicamente su navegabilidad).

Las bases para crear un prototipo

Si podemos jactarnos de tener muchas técnicas de desarrollo de software, éstas no existen en tal cantidad para el desarrollo de un prototipo adecuado. Hay demasiadas herramientas, su popularidad ha crecido muchísimo, pero hasta ahí ha llegado esta parte. Así que aquí tienen los que a mi juicio son tres puntos necesarios en el desarrollo de un prototipo.

1.- Un análisis satisfactorio: Quizá esto suene obvio, pero debe quedar bien claro, la idea de un prototipo es demostrar que las necesidades de nuestro cliente quedaron cubiertas en el análisis.

2.-Prueba de concepto: Saber hacia donde caminar es el inicio, crear el camino y como será recorrido es otro punto, aquí es en donde el prototipo debe demostrar como como cumplirá la aplicación con el uso de las herramientas que incluirá.

3.-Diseño de exploración: Este es el punto mas delicado, aquí el diseño de como funcionará la aplicación deberá quedar elaborado, los menús, las barras de tareas, opciones, menús contextuales, en resumen, todo elemento visible considerado y como llegar a él se deben demostrar aquí.

Para concluir

Un punto muy importante es que en los requerimientos iniciales de nuestro proyecto debimos especificar la tecnología con lo que realizaríamos nuestro producto, pero esta debe ser muy independiente de la elaboración del prototipo, dado que hasta este punto ambos elementos pueden ser completamente independientes.

La creación de un prototipo es una costumbre a la que nos debemos adaptar, a la que debemos adaptar a nuestro cliente y para bien mutuo, en franca codependencia para poder hacer funcionar todos los engranes que componen un correcto proceso de desarrollo de software y por ende una amplia satisfacción de nuestro cliente que siempre debe ser nuestra meta máxima.