PDF de programación - Comunicación de Arquitectura de Software - Arquitectura de Proyectos de IT

Arquitectura de Proyectos de IT








Comunicación de Arquitectura de Software

Apunte:





















Autores:

Ing. Gustavo A. Brey ([email protected])

Santiago Blanco ([email protected])











Versión: 0.8.20081106

1

1.
2.

3.

2.1.
2.2.
2.3.
2.3.1.
2.3.2.
2.3.3.
2.3.4.
2.3.5.
2.3.6.

Comunicación de Arquitectura de Software
[email protected] ..................................................................................................... 1
Comunicación de Arquitectura de Software .................................................................................... 2
Introducción....................................................................................................................... 3
Concepto de Comunicación y Entendimiento de Arquitectura ......................................... 3
¿Por qué comunicamos?........................................................................................... 3
Stakeholders y Necesidades ..................................................................................... 3
Elementos y relaciones.............................................................................................. 4
Stakeholders.......................................................................................................... 5
Concerns (Necesidades) ....................................................................................... 5
Viewpoints (Perspectivas) ..................................................................................... 5
View (Vista) ........................................................................................................... 5
Models (Modelos) .................................................................................................. 5
Architectural description ........................................................................................ 5
Frameworks de Arquitectura de Software......................................................................... 5
The 4+1 View Model of Architecture.......................................................................... 5
Logical View .......................................................................................................... 6
Development View................................................................................................. 6
Process View......................................................................................................... 6
Physical View ........................................................................................................ 6
Scenarios View...................................................................................................... 6
Guía/Metodología de Comunicación................................................................................. 6
Diagrama de Contexto y Overview Diagram ............................................................. 7
Identificar Stakeholders y Concerns .......................................................................... 7
Definir los ViewPoint necesitados.............................................................................. 7
Documentar y Comunicar las Vistas.......................................................................... 8
Documentar y Comunicar los Escenarios.................................................................. 8
Documentar las decisiones (Constantemente).......................................................... 8
Armado de SAD (Wiki, Documento de Texto, etc) .................................................... 8

3.1.
3.1.1.
3.1.2.
3.1.3.
3.1.4.
3.1.5.

4.

4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
4.7.



2

1.

Introducción



2.

Concepto de Comunicación y Entendimiento de Arqui-

tectura

2.1. ¿Por qué comunicamos?


La comunicación de la arquitectura tiene los siguientes usos.

• La Arquitectura como elemento principal para la comunicación entre stakeholders.


El tipo de comunicación, es decir, lo que se desea transmitir, variara de acuerdo a cada tipo de
stakeholder involucrado. Por ejemplo, a un tester, se le especificara la caja negra de las piezas
de software que deben ser testeadas, mientras que a los desarrolladores se les estaría comuni-
cando no solo el alcance del módulo o sistemas, sino también como construir la aplicación, sus
restricciones, principios, estilos arquitectónicos y entorno de desarrollo a utilizar (ej, IDE, DB,
como compartir el código, etc).
Pero sin duda que una de las personas más interesadas en la documentación de la arquitectura
es el arquitecto. En el futuro, el arquitecto puede ser la misma u otro persona, y en este ultimo
caso, estará mas interesado aun en contar un con documentación que le permita observar las
decisiones que se han tomado y el porque de las misma.


• La Arquitectura sirve como medio de educación.


El término de medio de educación proviene del hecho de que la documentación de arquitectura
es usada para introducir a nuevos trabajadores en el entendimiento del sistema. Estas personas
bien pueden ser nuevos empleados, analistas externos o un nuevo arquitecto.
Uno de los desafíos que nos hemos encontrado a lo largo de nuestra experiencia trabajando en
proyectos es la de mantener a todo el equipo correctamente comunicado sobre la organización,
tanto de los equipos como de los componentes de la aplicación, sus responsabilidades y depen-
dencias, y creemos que tener un correcto plan de comunicación de la arquitectura es clave para
poder lograrlo, y la arquitectura contiene dichas decisiones significativas que permiten la educa-
ción constante de los integrantes para los cambios durante la evolución y avance del proyecto.
Muchas veces mantener un único documento actualizado con las últimas decisiones no siempre
es lo más feliz y/o aconsejable, a lo largo del apunte veremos otros medios y que comunicar.


• La Arquitectura sirve como base para el análisis del sistema.


Esta documentación debe tener la información necesaria para poder evaluar una variedad de
atributos tales como seguridad, performance, usabilidad, disponibilidad y modificabilidad. Uno de
los pre requisitos para la evaluación de arquitecturas tiene que ver con tener la documentación
de la arquitectura actualizada, de esa manera pudiendo evaluar si una arquitectura va a poder
cumplir con los requerimientos, antes de implementar un sistema, es más que valorable.

2.2. Stakeholders y Necesidades

Es importante que la arquitectura necesita ser entendida y consensuada por los stakeholders. Lo
que simplemente dijimos en una linea, no es algo sencillo de lograr, con lo cual vamos a comen-
zar a mencionar a los stakeholders más importantes como para saber que necesitan de la arqui-
tectura.
Stakeholder

Necesidades

Cliente

Necesita saber sobre las solución va a contemplar con los requerimien-



3

Stakeholder

Necesidades

Project Manager


Infraestructura

tos del negocio que necesita el día a día para cumplir con sus objetivos.
El tiempo y el costo asociado siempre es clave para este stakeholder.

Es el principal responsable de que el proyecto cumpla con lo pedido
(alcance), en el tiempo que el negocio lo necesita y dentro del costo
estipulado. La arquitectura es su principal herramienta de negociación
frente al cliente, como así también para la organización de los equipos
de trabajo, asignación de tareas y seguimiento. Los planes de staffing,
compra de hardware y costos asociados son también importantes para
el Project Manager.

Necesitan entender como la aplicación será distribuida y donde debe
funcionar para poder tener la infraestructura (Hardware, Red, Sistemas
Operativos, Middleware, Bases de Datos) disponible para construir, tes-
tear y correr la aplicación en producción.

Analistas y Testers


No solo necesitan saber que es lo que el sistema proveerá al negocio,
sino también la manera (solución<=arquitectura) en la cual será resuel-
to. La arquitectura de un marco su trabajo.

Programadores
Diseñadores

y

Necesitan saber las responsabilidades del modulo que están constru-
yendo, si alcance, sus dependencias y maneras de comunicación (pro-
tocolos). Los principios y estilos arquitectónicos que fijan las libertades y
restricciones de constructibilidad.

2.3. Elementos y relaciones

Entendiendo lo importante que es la comunicación de la arquitectura y por que muchos roles
tienen que entenderla, comenzaremos a explicar un modelo que permite resolver esta problemá-
tica. Pudimos ver que cada rol tiene determinadas necesidades y cada uno de ellos tienen dife-
rentes experiencias y conocimientos, con lo cual es sencillo entender que es imposible comuni-
car una arquitectura de una única manera y en un único lenguaje. Teniendo clara esta base de la
comunicación de arquitecturas, el siguiente modelo nos permite visualizar los elementos y sus
relaciones que nos permitirán comunicar correctamente la arquitectura:



4



2.3.1. Stakeholders

Son todas las personas involucradas directa o indirectamente con el desarrollo de la aplicación
en cuestión, no necesariamente tienen que ser parte del equipo, pueden ser usuarios, usuarios
finales y/o usuarios indirectos.

2.3.2. Concerns (Necesidades)

Cuando hablamos de necesidades, estamos hablando de las incumbencias que tiene cada sta-
keholder con un sistema, dimos ejemplos en la sección Stakeholders y Necesidades sobre las
necesidades de los stakeholders más comunes, y pudimos ver que cada una de ellas son muy
variadas pasando de unos a otros lo cual requiere identificarlas, analizarlas y buscar la mejor
alternativa de comunicación para satisfacerla. Podemos ver que los stakeholders pueden tener
más de u