Sobre Arquitectura - Cuaderno II

LINK A LOS DOCUMENTOS MENCIONADOS EN ESTE ARTICULO AL PIE DE LA NOTA

Colegas
Seguimos en este cuaderno con las notas relacionadas a la arquitectura del software y repetimos el formato del envio
anterior:

-Opiniones e ideas de los adherentes a los métodos formales
-Opiniones e ideas de los adherentes a las metodologías agiles
-Un documento propio de M3, que al igual que el del envío anterior, es el diseño de arquitectura de un sistema.-



AtribDrivenDesign-A Practical Example.pdf:
A Practical Example of Applying Attribute-Driven Design (ADD)
*************************************************************
Este es un paper de William Wood (miembro eminente del SEI, redactor de especificaciones del DoD y promotor
de estas metodologias). Nos ha resultado muy interesante primero porque es una descripcion de un metodo
aplicado en un caso real. Pero en segundo lugar porque, si se sigue el texto con la misma seriedad con la que el autor lo
ha escrito,creo que llegaremos a la conclusion en que este metodo obliga a generar una documentacion tediosa que no parece
aportar valor al producto, al menos en proporcion al esfuerzo.

Queremos ser claros en esto, en terminos generales acordamos con una metodologia como puede ser esta, que a modo
de receta propone iteraciones hasta definir el modelo de arquitectura elegido.

Lo que no nos parece practico y esta es la diferencia esencial entre las metodologias agiles y las formales, es completar
un conjunto de documentacion , que NO ACTUA COMO CHECKLIST O AYUDA-MEMORIA sino como "jaula" de la expresion de un diseño.
Y si se piensa que esta posicion es demasiado extrema, es bueno leer los comentarios que en el punto 6 del paper realiza
el autor:

"...2. The documentation of the ADD results is awkward at times, since we documented development according to the structure
of the ADD method. The result was rather clumsy documentation with Section 4 having four levels of indentation and the
other sections having only one or two. However, in most real software architecture description documents, the documentation
structure will not be dependent on the development method (ADD) but rather on the most effective way of capturing the views
developed..."

Estos comentarios del Ingeniero Wood no solo nos parecen acertados conforme a lo que se deduce del informe, sino que muestran
el talento y la honestidad intelectual del autor.-

AGILE ENTERPRISE ARCHITECURE -Ambler.pdf
******************************************
En la segunda página de este documento, usted encontrara que Ambler asume ( A few Assumptions) que el lector debe haber
leído previamente los principios de las Metodologías Agiles.
Si bien esto es un plus, no es necesario haberlo hecho si esta realmente interesado en la discusión sobre el tema.
De modo que siga adelante con la lectura y tome esto solo como una parte de la "ferocidad" Ambler.

Lo importante no es el extremismo de Ambler sino la claridad de sus ideas.

Los tópicos del documento suenan como una buena fuente de consejos:

“Lo importante es la gente, no la tecnología” es uno de los lemas de este documento (una idea tomada de Brooks) que habla
sobre la importancia de convencer y generar sinergia por encima de las herramientas y las técnicas a usar.-

“Roll up your Sleeves” o sea ARREMANGARSE… y trabajar desde y con el equipo (y no desde la torre de marfil).-

“Mantenerlo simple”. El principio de menor complejidad aceptable para los diseños y arquitecturas

Solo por mencionar algunos de los puntos que se tocan en este documento de sencilla lectura.-

M3-Especificacion Arquitectura Emisión de Reportes v1-6.pdf
************************************************************
Este es un documento de arquitectura que creamos en Millennium3 para un software de benchmarking. Se trata de uno de esos
sistemas que hemos hecho durante años, en distintas tecnologías, lenguajes y épocas.-
Por eso mismo, nos ha permitido tomarlo como patrón para medir diferencias entre lenguajes y técnicas de implementación.
El documento sigue la línea del entregado con el envío anterior y se corresponde al patrón de documento que usamos para
estos casos.-
Creemos que muestra de modo adecuado como está (o estará) construido el sistema y como interactúan las partes.-


Este es el segundo envio sobre temas de arquitectura. Las consultas y opiniones recibidas nos llevan a que generemos un tercer envio
sobre el tema que distribuiremos en el mes de Marzo

Esperamos como siempre que estas lecturas sean de su interes y los inspiren en ,esta, nuestra creativa y amada actividad

Atentamente

LINK A LOS DOCUMENTOS:
http://www.linkedin.com/osview/canvas?_ch_page_id=1&_ch_panel_id=1&_ch_app_id=17798120&_applicationId=1300&appParams=%7B%22subview%22%3A%22shared%22%2C%22item_type%22%3A%22folder%22%2C%22shared_name%22%3A%225xau9onhts%22%7D&_ownerId=9863329&completeUrlHash=tnNC