Cómo diseñar una arquitectura de software: Consejos y prácticas

No sería adecuado iniciar un proyecto sin un plan sólido; lo mismo ocurre con el diseño de arquitectura de software. Al hacer que este proceso sea más eficaz, puedes justificar todos tus requisitos de manera adecuada y brindar a las partes interesadas la oportunidad de presentar sus aportaciones.

Mediante el uso de las imágenes técnicas y un cuidadoso proceso de planeación, puedes hacer un esbozo de la arquitectura y el diseño de tu software antes de empezar a crear un prototipo. 

¿Para qué sirve la arquitectura de software? 

El diseño de una arquitectura de software utiliza los conocimientos de programación para planear el diseño general del software de modo que puedan agregarse detalles más adelante, lo cual permite a los equipos de software delimitar el panorama general y comenzar a elaborar un prototipo. 

Si los desarrolladores de software siguen los consejos de diseño y las prácticas recomendadas de arquitectura de software, pueden analizar detalladamente las características de su software y decidir cómo diseñar la arquitectura de este. 

Cómo diseñar una arquitectura de software en 5 pasos:

1. Comprende claramente cuáles son tus requisitos

Todo diseño que comiences tendrá requisitos funcionales y no funcionales. Estos requisitos guían tu arquitectura de software y te permiten concluir el proyecto con la presentación de un producto final que deje satisfechas a las partes interesadas.

Si no tienes una comprensión clara de estos requisitos desde el principio, tu equipo corre el riesgo de perderse, dar prioridad a requisitos equivocados en detrimento de otros o utilizar una cantidad ineficaz de recursos internos. 

Obtén una mejor comprensión a través de imágenes. Sigue estos pasos para trazar tus requisitos en una plataforma de creación de diagramas inteligente como Lucidchart:

• Comienza con una visión general: primero, haz un resumen breve de tus requisitos con una “vista aérea”. Los mapas mentales son una forma eficaz de hacer esto. 

• Haz un mapa de tus requisitos funcionales: puedes usar verbos para agrupar sustantivos. Por ejemplo, verbos como “ver” y “editar” pueden vincular “cuenta” o “perfil” entre sí en un mapa mental de áreas funcionales. 

• Ten en consideración los requisitos no funcionales: mientras trabajas en tu mapa mental, puedes anotar tus requisitos no funcionales para utilizarlos más adelante. Un requisito como “desempeño” es clave, pero probablemente sea demasiado abstracto para colocarlo en el mapa mental. 

Tus requisitos deben utilizarse para definir el alcance del trabajo y planear el proyecto.

2. Comienza a pensar en cada componente

Seamos sinceros: con la poderosa influencia que tienen los requisitos funcionales en tu proyecto, es posible que tus opciones de diseño y tecnología ya estén decididas una vez que hayas definido tus requisitos. 

Es necesario que averigües qué requisitos plantearán desafíos importantes para tu diseño o plan de proyecto, sin adelantarte demasiado al pensar en la implementación. Algunos requisitos pueden ser imposibles de cumplir bajo ciertos supuestos u opciones. 

• Empieza con el “escenario perfecto”: ¿Cómo sería tu diseño si pudieras crearlo de manera perfecta? 

• Considera y documenta qué implicaciones tienen tus requisitos: comienza a elaborar un borrador de trabajo con tu equipo y desarróllalo gradualmente. En primer lugar, debes observar lo que implican los requisitos en tu diseño; por ejemplo, en qué aspectos los elementos individuales de la lista de deseos de las partes interesadas pueden contradecirse entre sí o estar en conflicto con otros requisitos funcionales y no funcionales. 

• Espera y realiza el diseño de la arquitectura final más adelante: lo más probable es que hagas cambios en tu planeación a lo largo de este proceso, así que no esperes que el primer borrador se parezca mucho al resultado final. 

3. Divide tu arquitectura en “rebanadas”

Tu diseño de arquitectura, por supuesto, pasa a una fase de planeación a medida que decides cómo vas a entregar tu diseño. Al dividir tu arquitectura en rebanadas, puede resultar más fácil la elaboración de este plan, de tal manera que proporcione beneficios a los usuarios y sirva para planear adecuadamente tu uso de los recursos de desarrollo. 

Para esto, es útil pensar en cómo se rebana un pastel. La mayoría de la gente lo hace pasando el cuchillo por cada una de las capas. Digamos que una rebanada completa tiene glaseado, relleno y dos o tres capas de bizcocho en su interior. Esta rebanada vertical tiene un poco de todos los ingredientes. Un pastel también puede rebanarse horizontalmente, separando cada una de las capas. 

De manera similar, si cada rebanada es un piso que se utiliza para planear la arquitectura de tu software, entonces hay capas. Si rebanas el pastel verticalmente, creas pisos enfocados en características individuales, mientras que, si lo rebanas horizontalmente, se muestran los componentes individuales. Necesitas tener una mentalidad tanto horizontal como vertical para tu proyecto. 

Agile se enfoca en las rebanadas verticales, lo que permite a tu equipo ofrecer beneficios rápidamente. Este enfoque permite a los clientes conocer con rapidez el progreso del producto y al equipo de desarrollo recibir información sobre cada una de las capas de una función. Una rebanada vertical de la arquitectura de tu software para un sitio web de comercio electrónico podría ser el proceso de pago. 

En tu rebanada de pastel vertical de “proceso de pago”, puedes ver la capa de datos que almacena la información del pago, la API de la capa intermedia y la interfaz de usuario de la capa superior que ven los compradores. Con las rebanadas verticales, puedes decidir qué funciones entregar y elegir piezas iterativas.

Al hacer diagramas de las capas involucradas en tu proyecto de arquitectura de software, puedes visualizar toda la pieza y cómo influye cada capa en otras capas. A medida que elaboras tu plan, toma cada rebanada de pastel de Agile y haz un diagrama de cómo se conectan las rebanadas entre sí.

4. Hacer un prototipo

Siempre crea un prototipo. Los prototipos te permiten descubrir fallas de forma rápida y temprana, por lo que obtendrás retroalimentación con rapidez y podrás descubrir tu prueba de concepto. Esta es una parte importante de la validación de tu trabajo y de la comprobación de tus supuestos para asegurarte de que sean válidos y minuciosos. 

Al crear tu prototipo, recuerda que las primeras iteraciones nunca serán perfectas y ninguna iteración final será completamente perfecta. Una de las ventajas de la creación de prototipos es que no se presenta como un producto acabado, y la mayoría de las personas inicia por instinto un proceso de elaboración de prototipo esperando al menos encontrar algunas fallas. 

Aprovecha la fase de elaboración del prototipo. Esto no sustituye a las pruebas, pero es una parte crucial de las pruebas que deberás realizar. 

• Mantén un historial de cambios riguroso: por supuesto, si no documentas lo que vas descubriendo en la creación de los prototipos, corres el riesgo de repetir tus errores. Anota todo: documenta minuciosamente tus decisiones de diseño y los cambios que realices sobre la marcha.

• Ten una sola fuente de información: no será conveniente que tengas múltiples cambios y diferentes versiones que frenen tu progreso, así que establece un sólido control de versiones basadas en una única fuente de información para tu documentación. 

• Haz diagramas de tus prototipos: puedes usar diagramas para ayudarte a administrar los cambios de prototipos y visualizar las diferencias entre cada versión. 

5. Identifica y cuantifica los requisitos no funcionales

Además de los requisitos funcionales, deberás tener en cuenta los requisitos no funcionales. Estos requisitos son tan importantes como tus requisitos funcionales para el diseño porque definen las características del sistema. 

Los requisitos no funcionales normalmente son los requisitos de calidad general para todo el proyecto, pero no siempre. Es posible que tu sistema tenga requisitos no funcionales específicos solo para una parte de tu arquitectura de software. Por lo tanto, hay que estar preparados para incluir a las partes interesadas en los requisitos locales no funcionales. Por ejemplo, una rebanada vertical particular del proyecto puede interesar al equipo de atención al cliente en especial, y ese equipo puede tener sus propias expectativas sobre esos requisitos no funcionales.

Sin embargo, no es suficiente decir que deseas tener desempeño, portabilidad o escalabilidad. Los requisitos no funcionales también deben cuantificarse. Ningún proyecto puede tener un desempeño absolutamente perfecto: el “desempeño” debe especificarse y delimitarse para cumplir con otros requisitos. 

Dado que tus requisitos no funcionales ocupan un lugar en la configuración de tu diseño, no puedes evitar definirlos. A continuación, se detallan otros requisitos que puedes tener en cuenta:

• Desempeño: qué tan bien funciona todo tu sistema, así como las rebanadas o capas individuales.

• Escalabilidad: el potencial actual y futuro para escalar tu sistema junto con tus necesidades.

• Portabilidad: la portabilidad de tus datos, así como la posible portabilidad de los componentes de tu sistema si procede o es necesario.

• Extensibilidad: explica el crecimiento futuro de tu sistema y de tu empresa, la capacidad de adaptación de tu sistema y el esfuerzo que conlleva la adaptación.

• Cumplimiento normativo: es otro factor esencial y que tiene un impacto importante en el diseño general de tu proyecto.

Elaborar un diagrama de tus requisitos no funcionales puede ayudar a tu equipo a ver cómo los cuantificas y, a la vez, coloca los requisitos específicos en contextos relevantes. Aunque no tienes que preocuparte por optimizar todo en este punto, también hay que considerar el esfuerzo y los recursos que pueden ser necesarios para optimizar estos requisitos no funcionales más adelante. 

Prácticas recomendadas para el diseño de arquitectura de software

A medida que emprendes tu proyecto de diseño, estas prácticas recomendadas te ayudarán a mantenerte fundamentado en buenos principios de diseño. 

Visualiza tu diseño 

El uso de elementos visuales en todo tu trabajo conceptual de diseño, así como en tu implementación, permite a tu equipo ver la perspectiva general en la que se basa tu diseño. Los diagramas son una excelente forma de visualizar procesos y diferentes aspectos de tus opciones de diseño.

No elijas patrones 

Mantén tu proceso de diseño enfocado en el panorama general sin recurrir a los patrones como punto de partida. En lugar de usar patrones, mantén un nivel muy general con una visión de los componentes principales para reducir el riesgo de tener una sobreingeniería de tus sistemas. 

Recuerda que el primer diseño es solo la primera iteración. 

Con tu primer diseño, tendrás una mejor idea de los desafíos y obstáculos técnicos que enfrentarás en el desarrollo de tu arquitectura. No esperes que el primer diseño sea algo más que un prototipo. 

No te preocupes: tu diseño de arquitectura crecerá y se desarrollará, lo que te permitirá descubrir más detalles con el tiempo. 

Ten cuidado con el crecimiento excesivo del alcance 

Si bien puede ser tentador permitir que se amplíe tu alcance, el crecimiento excesivo sacrificaría tus otros requisitos y podría acabarse los recursos necesarios. Para detener el crecimiento excesivo del alcance del proyecto, establece un borrador del plan de proyecto de trabajo que justifique tus requisitos y ten una conversación con las partes interesadas acerca de los límites de los requisitos no funcionales. No sería conveniente que alguna expectativa no cubierta afecte de forma negativa tu proyecto. 

Ten presente los límites y las interfaces

Mientras planeas tu diseño, ten en cuenta las interfaces entre componentes e identifica los límites de tu sistema. Comienza a asignar responsabilidades para que, cuando trabajes en tus prototipos y en las próximas iteraciones, tengas esta información a la mano a fin de facilitar su consulta.

Mejora el diseño de tu arquitectura de software ahora

El diseño de una arquitectura de software es más eficaz cuando existe un plan, la aportación de las partes interesadas y el enfoque adecuado para esbozar los requisitos del proyecto. No escatimes en esta planificación inicial y tus esfuerzos se verán recompensados con una experiencia de proyecto más fluida.