En un webminar del día de hoy vi la siguiente frase:
Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.
Alan Kay – Uno de los creadores de Smalltalk
Read More »
El énfasis de la solución del ingeniero de software se encuentra en los aspectos técnicos. La del arquitecto en el contexto del negocio.
La razón principal de la Arquitectura de Software reside en el que el análisis y diseño no son suficientes para resolver el problema. En la mayoría de los sistemas empresariales es muy importante tomar en cuenta los requerimientos no funcionales (conocidos también como Atributos de Calidad). En la presentación de Arquitectura de Software (SG 2007) se encuentra mayor información – láminas 6 – 49.
Alan Cooper resume muy bien esta idea:
Architects synthesize people, purpose, and technology. If you just take people and technology, you have art and entertainment. If you just take technology and purpose, it’s engineering. And people and purpose without technology is psychology. Architects have to synthesize all this, to create a vision of a solution. People must get something practical achieved.
La negociación es una de las habilidades críticas que todo arquitecto de software debe tener.
El arquitecto de software interactúa con la mayoría de los stakeholders de un proyecto. Algunas de estas interacciones requieren habilidades de negociación. Por ejemplo, una de los principales metas de la arquitectura es reducir el riesgo a su minima expresión en las fases tempranas del proyecto. Dado que los riesgos están asociados con requerimientos, una manera de reducirlos o minimizarlos es eliminar o modificar dicho requerimiento. De ahí la necesidad de negociar tales requerimientos para llegar a una solución mutuamente aceptable entre el arquitecto y el stakeholder. Para ello es necesario que el arquitecto sea un buen negociador, capaz de conciliar intereses.
Una vista es una representación de uno o más aspectos estructurales que ilustra como la arquitectura se ocupa de uno o más de los intereses de los stakeholders.
La idea no es nueva, sin embargo fue hasta 1995 cuando Phillipe Krutchen la hizo popular en su famoso manifiesto: Architectural Blueprints—The “4+1” View Model of Software Architecture.
A partir de ahí, todas las metodologías modernas para la elaboración de arquitecturas de software utilizan vistas.
El objetivo de un tipo de vista es proporcionar una librería de plantillas y patrones que puedan ser usados como la guía para la creación de vistas, ya que no sería práctico que cada vez que se definiera una vista se tuviera que especificar el tipo de contenido, guías, principios y modelos para su elaboración.
Un catálogo de los tipos de vistas puede ser el siguiente:
Read More »
