Para toda persona que trabaja en diseño, sin importar de qué objeto o creación se trate, los cambios son una parte inevitable del proceso. Algunas disciplinas permiten una flexibilidad que hacen que los cambios ayuden a mejorar el producto final. Sin embargo, en otras, como la ingeniería o la arquitectura, estas posibilidades son más limitadas y deben estar mejor calculadas, ya que una modificación en un etapa puede desestructurar el objeto final.
El desarrollo de software forma parte de este grupo. Un cambio es un pedido que realiza el cliente a través del cual solicita una modificación de un requerimiento previamente definido o para añadir uno nuevo. Para evitar que un proyecto se hunda en el caos absoluto ante cualquier pedido será necesario prepararse para gestionarlos de la mejor forma posible para diseñar una aplicación robusta y permeable a las modificaciones, con el objetivo de minimizar los impactos negativos que estos pudieran ocasionar en otras áreas o módulos que la integran.
Teniendo en cuenta esta realidad, habrá que trabajar desde el inicio en el armado de la arquitectura, en el diseño de un módulo y en la programación de una funcionalidad, para que al llegar un pedido de cambio se neutralice un posible impacto negativo de su implementación. Tomar acciones tempranas ayuda a diseñar y a construir una aplicación preparada para recibir cambios, es decir, que sea a la vez permeable a las modificaciones y robusta en su desempeño a medida que crece.
Luego de varios años y teniendo en cuenta las diferentes etapas de diseño y construcción de una aplicación, en Baufest elaboramos una lista de criterios para que al momento de tener que implementar uno o más cambios, se minimice el riesgo y mitigue el impacto negativo de estas tareas.
Como primera medida, hay que pensar y diseñar la arquitectura de la solución y tener en cuenta que a medida que se avance existen grandes probabilidades de sufrir modificaciones. Es fundamental entender que la arquitectura es dinámica, y que debe ser lo primero adaptable al cambio en un sistema.
Para asegurarse de tener un mejor diseño desde el inicio, y antes de comenzar con las tareas de construcción de la aplicación, será fundamental consensuar la arquitectura con el equipo de trabajo y, en caso que lo haya, con el equipo técnico de nuestro cliente y tener en cuenta las siguientes recomendaciones:
ì Plantear la solución de forma modular, identificando de manera temprana las funcionalidades que conforman la aplicación para lograr un bajo acoplamiento entre ellas. Si hubiera que integrar dos o más funcionalidades, una buena estrategia a seguir es utilizar interfaces que nos abstraigan de los detalles de la implementación particular de cada una de ellas.
ì A fin de mantener homogénea la solución, fomentar que todo el equipo hable el mismo idioma para mitigar riesgos; es esencial definir y comunicar los estándares de construcción y codificación que se van a utilizar, y también estandarizar y promover el uso de Patrones de Arquitectura y Diseño.
ì A la hora de diseñar la solución, es muy importante hacer una clara separación entre las diferentes capas que van a conformar la misma. Es muy importante establecer una correcta separación entre la interfaz de usuario y la lógica de negocio. Es más sencillo y menos riesgoso hacer las modificaciones si los componentes de la solución se encuentran correctamente separados.
Como todo diseño, el proceso de creación es una tarea compartida; pensar los detalles desde el inicio es clave para llegar de manera exitosa a la meta.
