Cuando se nos plantea el reto de realizar el desarrollo de una aplicación para un cliente suceden muchas cosas antes de que comencemos a escribir las primeras líneas de código.
En esta serie de artículos vamos a intentar ir desgranando cada uno de los pasos que nos afectan de manera más directa a los desarrolladores. Profundizar en las problemáticas más comunes a la hora de afrontar el reto de llevar a buen término la creación de una aplicación de calidad para nuestro cliente.
Por lo tanto, antes de comenzar a escribir nuestro código tenemos que afrontar una serie de problemáticas:
- Fase de toma de requerimientos.
- Entornos de desarrollo y producción.
- Código seguro y trabajo en equipo.
Si conseguimos reducir el número de problemas que se ocasionan en estos tres pasos previos a escribir nuestras primeras líneas de código podemos asegurar que nuestra aplicación va a ser mucho más sencilla de realizar, y con una calidad muy superior a si empezamos a programar desde el primer momento por las prisas de llegar tarde a los plazos de entrega.
La primera parte y quizás una de las más esenciales es la toma de requerimientos en el cliente, por desgracia en muchos entornos de trabajo se tiende a subestimar esta fase, ya que se piensa que si se emplea mucho tiempo en ella no lo estamos invirtiendo en comenzar el desarrollo propiamente dicho. Este tipo de error es lo que nos lleva a entender mal lo que el cliente quiere de la aplicación, y después, cuando ya nos encontramos en la fase de desarrollo, cosas que no han sido incluidas, han sido definidas incorrectamente, o mal interpretadas por nuestra parte, cuando se las presentamos al cliente en el aplicativo y este nos indique que no es lo que quería, realizando una serie de cambios que puede llegar a ser catastróficos para nuestras planificaciones, por lo tanto esta es una fase que hay que dejar muy bien definida, y la inversión de unas horas en ella puede evitarnos costes de días enteros en la fase de desarrollo, además de la desconfianza que podemos generar en el cliente al ver que no hemos sabido interpretar lo que necesita.
Por lo tanto, una vez hemos realizada la toma de requerimientos es muy sencillo crear unos mockups o prototipos sin funcionalidad que se le presentan al cliente para que de manera visual pueda validar la funcionalidad que se le presenta como solución a sus requerimientos, y en caso de que este encuentre alguna carencia, mala interpretación o fallo, se corrige rápidamente, únicamente modificando dichos mockups, hasta encontrar aquello que el cliente necesita.
Además, esta técnica nos permite mostrar de manera visual soluciones que el cliente no había pensado que le podían ser útiles hasta ese momento y que pueden facilitar tanto el desarrollo como los requerimientos de la aplicación, con el consecuente ahorro en costes y lo que es más importante, la satisfacción del cliente por ver de manera sencilla soluciones válidas a sus problemas y alternativas de valor al software que se le está preparando.
También nos ayuda mucho para que nuestra aplicación tenga un alto nivel de UX (experiencia del usuario), que sea de fácil uso por parte de propios usuarios, ya que son ellos mismo los que pueden decirnos qué opciones son las que más utilizan en su día a día y darle un mayor peso y accesibilidad dentro de la aplicación, y cuáles son las que no utilizan con tanta asiduidad, dándoles un papel menos importante en la aplicación y pudiendo generar así interfaces claras y sencilla para los usuarios. Esto lo podemos lograr presentando estos mockups a los propios usuarios y validarlos con ellos, ya que los desarrolladores no podemos llegar a saber qué funcionalidades son más o menos utilizadas si no es con la propia experiencia del usuario final.
Y por último, a la hora de comenzar a programar, es mucho más sencillo poder presentar cuales son los requerimientos de la aplicación a los programadores, enseñando estos mockups, e indicando directamente que es lo que se necesita, teniendo una visión global de la funcionalidad de la aplicación con unas cuantas transparencias, y una visión detallada de las partes que le corresponden a cada uno de los programadores, siendo más sencillo la asignación de tareas repartiendo los propios mockups entre los grupos de trabajo.
Para poder realizar estos mockups nosotros utilizamos la herramienta Balsamiq, la cual vamos a presentar a continuación de forma sencilla para mostrar la potencia de esta técnica, pero hay muchas más herramientas en el mercado para implementarlos.
Como ejemplo base vamos a desarrollar un CRUD para la gestión de usuarios de nuestra aplicación.
En la toma de requerimientos que se hace con el cliente obtenemos que este quiere poder gestionar los usuarios que tienen acceso a la aplicación, pudiendo dar de alta, baja y modificarlos. Estos usuarios pueden pertenecer a distintos grupos que permitirán acceder a distintas partes de la aplicación en función de los permisos que tenga cada grupo. El cliente también quiere poder activar y desactivar usuarios de manera temporal por si en cierto momento quiere no permitir el acceso a alguno de ellos. Cada usuario debe tener un nombre y una contraseña que pueden autogestionar ellos mismos desde dentro de la aplicación, no solo los administradores del sistema.
Con esta toma de requerimientos planteamos los siguientes mockups que desarrollamos con Balsamiq.
Para este artículo utilizamos la versión de prueba en entorno web asociada con Google Drive, existiendo varias alternativas más, como la de escritorio, o en la nube, si os es más cómodo.
Esta se ve de la siguiente manera:
En la parte superior encontraremos las funcionalidades que nos permiten la gestión de los proyectos, ya que la herramienta permite crear todos los mockups pertenecientes a una aplicación en un mismo proyecto.
Justo debajo aparecen todas las opciones de edición y visualización, además también ofrece la posibilidad de colaboración, permitiendo que otros usuarios tengan acceso al proyecto pudiendo colaborar en el mismo bajo invitación del propietario.
Ya en la interfaz de trabajo propiamente dicho, encontramos todos los controles que se pueden utilizar para simular los posibles objetos que vamos a utilizar para hacer nuestra aplicación.
Incorporando la posibilidad de añadir nuevos controles mediante un enlace que nos muestra más posibilidades que van creciendo poco a poco en la propia web del aplicativo.
La zona de trabajo se encuentra dividida en tres partes
La parte izquierda donde nos encontraremos los mockups de cada una de las pantallas.
La parte central, donde desarrollaremos cada uno de los mockups arrastrando los controles de la barra superior, y editándolos mediante doble click sobre los mismos, y en la parte derecha las propiedades de cada uno de los controles que vamos incorporando, y donde aparte del aspecto, podemos controlar los eventos que están asociados a cada uno de los controles, ya que cuando activamos el modo presentación podemos interactuar con cada uno de los controles definidos como si fuese la aplicación propiamente dicha haciendo una demostración viva con la que nuestro cliente puede interactuar..
Vamos a comprobar el resultado de nuestros mockups asociados a las especificaciones que hemos obtenido de nuestra fase de requerimientos con el cliente de ejemplo.
Toma de requerimientos:
El cliente quiere poder gestionar los usuarios que tienen acceso a la aplicación.
pudiendo dar de alta
baja,
y modificación.
Estos usuarios pueden pertenecer a distintos grupos que permitirán acceder a distintas partes de la aplicación en función de los permisos que tenga cada grupo.
El cliente también quiere poder activar y desactivar usuarios de manera temporal por si en cierto momento quiere no permitir el acceso a alguno de ellos.
Cada usuario debe tener un nombre y una contraseña que pueden autogestionar ellos mismos, no solo los administradores del sistema.
Con todos y cada uno de estos mockups hemos recogido todas las funcionalidades que el cliente nos ha solicitado para la aplicación, en este momento si mostramos el modo de presentación del cual dejo un vídeo, el cliente puede ver de forma visual y directa si es lo que necesita o si por el contrario necesita algún cambio.
Por ejemplo, nos puede indicar que el orden de los campos de la grid en la que aparecen los usuarios no es el que quiere, porque prefiere que aparezcan los grupos de usuarios antes de la columna de activo.
Nosotros en un momento podemos modificar el mockup y mostrárselos para ver efecto deseado.
Y con esto el cliente verifica que esto es lo que necesita.
Tras tener clara toda la especificación y una vez verificada toda la aplicación por el cliente ya la podemos pasar a nuestros desarrolladores, los cuales pueden partir de una idea muy clara de las necesidades y las pueden plasmar con mayor facilidad convirtiendo la idea inicial en una realidad.
En nuestro caso mostramos algunos ejemplos de los mockups llevados a la realidad del aplicativo.
Espero que esta breve presentación de esta primera problemática que nos encontramos antes de comenzar a programar una aplicación y la herramienta que nos permite solucionar os hayan servido de ayuda.
Por suerte la tecnología no está solamente al alcance de nuestros clientes, y nosotros como desarrolladores también tenemos la posibilidad de utilizar herramientas que nos ayudan a implementar técnicas de programación que nos permitan desarrollar un software de calidad y con un coste menor, de esta manera tendremos satisfechos a nuestros clientes, y nosotros también podremos disfrutar mucho más de nuestro trabajo, no teniendo que enfrentarnos a retrasos y tiempos de planificación ajustados por errores de base.
Para el siguiente artículo nos centraremos en los entornos de desarrollo y producción donde vamos a implantar nuestras aplicaciones. Este asunto también es problemático, y para ello haremos uso de nuevo de tecnologías que nos hagan la vida más fácil, en este caso máquinas virtuales que nos permitan simular estos entornos con independencia del software y que nos facilitaran entre otras cosas realizar una buena batería de pruebas para volver a entregar un software de calidad, pero esto ya es otro tema…
Os espero en el siguiente artículo.
