OpenUp, un sitio que volví a encontrar

 

"Dos cosas son infinitas: el universo y la estupidez humana;

y yo no estoy seguro sobre el universo."  

Albert Einstein

La mente creativa, el ingenio humano para buscar otro camino, siempre me ha causado risa cuando sale uno de la oficina  y el problema sigue en backend procesándose, ese hilo no muere hasta recibir respuesta,  entonces como si se hubiese olvidado estas en otra actividad y de pronto viene la idea, la solución y como loco hablas en voz alta “¡claro que estupidez ahí está el error!”.

 Estos días he seguido leyendo sobre arquitectura y me he acordado de páginas que alguna vez leí, y tome como fuente de trabajo, analizando que los conceptos los hemos trabajado aplicado, aun así cuando la pregunta viene formulada en un marco diferente nos enredamos. Entonces en ese cuestionamiento llego mi dejavu mental  “La arquitectura del software es un concepto fácil de entender y que la mayoría de los ingenieros intuitivamente siente, especialmente con un poco de experiencia, pero es precisamente difícil de definir. En particular es difícil marcar una línea en lo que es diseño y arquitectura. La arquitectura es un aspecto del diseño que se concentra en algunas características específicas.” Dónde lo había leído, si la página que hoy volví a recordar abrí el explorador http://epf.eclipse.org/wikis/openupsp/,  a leer un poco de OpenUP, quise traer al blog algunos de los conceptos,

 

OpenUP se basa en cuatro principios básicos que se apoyan mutuamente:

Colaborar para alinear los intereses y un entendimiento compartido

Desarrollar prácticas que fomenten un ambiente de equipo saludable. Un ambiente de equipo saludable permite la colaboración efectiva, lo cual encuadra los intereses de los participantes del proyecto (equipo de desarrollo, aseguramiento de la calidad, stakeholders del producto, clientes) y ayuda a los participantes del proyecto a desarrollar un entendimiento compartido del proyecto.

Balancear las prioridades en contradicción para maximizar el valor de los stakeholder

Los sistemas necesitan ser desarrollado por equilibrar las diferencias y algunas veces perspectivas contradictorias. Por ejemplo, ¿usted prefiere minimizar el costo reutilizando una capacidad existente o hace un desarrollo personalizado de la capacidad para que haga exactamente lo que usted quiere?

Por consiguiente, los participantes del proyecto y los stakeholders deben colaborar para desarrollar una solución que maximice el beneficio de los stakeholders y cumpla con las restricciones planteadas en el proyecto. Lograr un balance es un proceso dinámico porque si los stakeholders y los participantes del proyecto aprenden más acerca del sistema, entonces sus prioridades y restricciones cambian.

Enfocarse en articular la arquitectura

Sin un fundamento arquitectónico, un sistema evolucionará en una forma ineficiente y casual. Tal sistema frecuentemente presenta dificultades para evolucionar, reutilizarse o integrarse sin una reconstrucción sustancial. Esto también dificulta organizar el equipo o comunicar las ideas sin el enfoque técnico común que la arquitectura proporciona.

Por consiguiente, use la arquitectura como un punto focal para que los desarrolladores alineen sus intereses e ideas, articulando las decisiones técnicas esenciales a través de una arquitectura creciente.

Evolucionar para obtener continuamente retroalimentación y progreso

Usualmente no es posible conocer todas las necesidades de los stakeholders, ser consciente de todos los riesgos, comprender todas las tecnologías del proyecto, en otros factores, es probable que cambien durante la vida del proyecto. Por consiguiente, divida el proyecto en mini proyectos, iteraciones encajadas en tiempo para demostrar valor incremental y obtener retroalimentación temprana y continua.

 Por ahora solo es el re encuentro.