Muy bien, ya sabemos qué es lo que el cliente necesita, conocemos las tablas que haremos, como se relacionarán entre ellas y la manera en la que debemos implementar nuestro diseño. Todo esta listo para comenzar a programar, pero; hay demasiado por hacer, ¿por dónde es mejor comenzar?

Ese es un problema bastante comunidad entre algunos programadores, el no saber qué desarrollar primero y de ahí, partir al resto. Pues, en el capítulo 7 del libro se nos habla justamente sobre cómo enfrentar ese problema.

Entra en juego un concepto llamado «arquitectura» y el libro lo define de la siguiente manera:

«Arquitectura es la estructura organizacional de un sistema, incluye su descomposición en partes, su conectividad, sus mecanismos de interacción y la guía de principios y decisiones que usas para el diseño del sistema».

En sí, la función de la arquitectura en un sistema es convertir un caótico desastre en una aplicación ordenada y funcional.

Por lo general se inicia la construcción de la arquitectura con las características funcionales del sistema, es decir, todo lo que un sistema es capaz de hacer y lo que le da vida a la interacción del usuario.

Pero, ¿cómo podemos identificar cuales son las tareas de mayor prioridad? Una estrategia utilizada es evaluar las funciones con una serie de preguntas denominadas las tres Q’s de la arquitectura.

¿Es una parte fundamental del sistema?

Es decir, ¿la función que estoy analizando mantiene mi sistema con vida? ¿Si esta función falla, todo o la mayoría de mi sistema fallará también? En caso de ser así, es una función con muy alta prioridad que debe funcionar a la perfección.

¿Qué tareas realiza la función?

Es muy importante conocer a la perfección qué es lo que hará lo que estoy a punto de programar, quizá suena muy obvio al principio, pero es común (al menos a mí me ha sucedido) que en sistemas con capacidades muy grandes es posible que no estemos todo el tiempo seguros de todo lo que estamos haciendo, y esta bien, es totalmente válido preguntar cuando se necesite.

¿Cómo puedo programar esa función?

Antes de comenzar a teclear como loco, lo ideal es tener un plan de implementación, es decir, haber analizado el contexto, la arquitectura en sí del sistema y encontrar, inclusive a nivel de pseudocódigo, la manera en la que podremos desarrollar lo que se nos ha asignado.

Una vez que nosotros analicemos todas las funciones que creamos que son las más importantes a través de la técnica de las 3 Q’s será cuestión de tiempo que tengas muy bien identificadas cuales son aquellas a las que se les deberá dar prioridad, y será ahí cuando sabrás por dónde comenzar.

El conjunto de funciones principales debe cubrir la esencia del sistema, es decir:

«La esencia de un sistema es lo que el sistema hace en su más básico nivel»

Además, existe otro motivo muy importante por el cual se deben atender primero las funciones de alta prioridad y es el riesgo.

El motivo por el que una función se denomina de riesgo es debido a que tiene a provocar daño importante a la integridad del sistema en caso de que este falle, es decir, genera riesgo al proyecto, por lo que se les debe dar alta prioridad y supervisión.

Mi consejo en este post es:

Concentrate en desarrollar una función a la vez, esto reducirá el riesgo para el proyecto, te dará tiempo para generar versiones estables que podrás ir perfeccionando, NO pierdas tiempo desarrollando funciones que no representan riesgo, esas se irán añadiendo conforme el proyecto vaya avanzando.

 

Fuentes consultadas:

HFOOAD: Capítulo 7 Traer el órden al caos.

https://es.wikipedia.org/wiki/Arquitectura_de_software

https://www.test-institute.org/What_Is_Software_Risk_And_Software_Risk_Management.php

Photo by rawpixel.com from Pexels