Documente Academic
Documente Profesional
Documente Cultură
Indice general
Acknowledgements XI
Dedication XIII
1. Introduccion 1
2. Arquitectura de TI 3
2.1. Arquitectura de software . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Arquitectura empresarial . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Tipos de arquitectos de software . . . . . . . . . . . . . . . . . . 6
2.3.1. Arquitecto tecnico . . . . . . . . . . . . . . . . . . . . . . 6
2.3.2. Arquitecto funcional . . . . . . . . . . . . . . . . . . . . . 7
2.3.3. Arquitecto Empresarial . . . . . . . . . . . . . . . . . . . 7
2.4. Competencias de un arquitecto . . . . . . . . . . . . . . . . . . . 7
2.4.1. Habilidades humanas . . . . . . . . . . . . . . . . . . . . . 7
2.4.2. Habilidades tecnicas . . . . . . . . . . . . . . . . . . . . . 7
2.5. Importancia de la descripcion de arquitectura . . . . . . . . . . . 8
2.6. Dise no de arquitectura . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6.1. Dise no de alto nivel . . . . . . . . . . . . . . . . . . . . . 9
2.6.2. Dise no de bajo nivel . . . . . . . . . . . . . . . . . . . . . 9
2.7. Lenguajes de descripcion de arquitectura (ALDs) . . . . . . . . . 10
2.7.1. UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.7.2. SysML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.7.3. ARCHIMATE . . . . . . . . . . . . . . . . . . . . . . . . 11
2.7.4. BPMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.8. Frameworks de arquitectura . . . . . . . . . . . . . . . . . . . . . 13
2.8.1. Frameworks de proposito general - . . . . . . . . . . . . . 15
2.8.2. Frameworks de dominio especco - . . . . . . . . . . . . . 15
2.8.3. Tipicacion de frameworks . . . . . . . . . . . . . . . . . 15
3. Descripcion ISO/IEC/IEEE 42010 17
4. Situacion actual de las empresas bogotanas 19
iii
iv
INDICE GENERAL
5. Modelos para la descripcion de una arquitectura basada en la
norma ISO/IEC/IEEE-42010 31
5.1. Modelos para la descripcion de una arquitectura basada en la
norma ISO/IEC/IEEE-42010 . . . . . . . . . . . . . . . . . . . . 32
5.2. Descripcion de la norma ISO/IEC/IEEE-42010 . . . . . . . . . . 32
5.3. Modelos Propuestos . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.4. Trabajo Por Realizar . . . . . . . . . . . . . . . . . . . . . . . . . 42
A. Traduccion de la norma ISO/IEC/IEEE 42010 43
A.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
A.1.1. Deniciones encontradas en la norma . . . . . . . . . . . . 43
A.1.2. Conceptos encontrados en la norma . . . . . . . . . . . . 45
A.2. Descripcion de la arquitectura . . . . . . . . . . . . . . . . . . . . 50
A.2.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . 50
A.2.2. Identicacion e informacion general . . . . . . . . . . . . . 50
A.2.3. Vistas de arquitectura . . . . . . . . . . . . . . . . . . . . 51
A.2.4. Identicacion de Stakeholders e interes . . . . . . . . . . . 52
A.2.5. Modelos de arquitectura . . . . . . . . . . . . . . . . . . . 53
A.2.6. Reglas de relaciones . . . . . . . . . . . . . . . . . . . . . 53
A.2.7. Justicacion de la arquitectura . . . . . . . . . . . . . . . 53
A.2.8. Relacion de arquitectura . . . . . . . . . . . . . . . . . . . 53
A.2.9. Registro de decisiones . . . . . . . . . . . . . . . . . . . . 55
A.2.10. Adherencia de una AD y un AF . . . . . . . . . . . . . . 55
A.3. Frameworks de arquitectura y ADLs . . . . . . . . . . . . . . . . 56
A.3.1. Frameworks de arquitectura . . . . . . . . . . . . . . . . . 56
A.3.2. Lenguajes de descripcion de arquitectura . . . . . . . . . 56
A.4. Puntos de vista de arquitectura . . . . . . . . . . . . . . . . . . . 56
A.5. Anexo A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
A.5.1. Notas en terminos de conceptos . . . . . . . . . . . . . . . 57
A.5.2. Sistemas y Arquitecturas . . . . . . . . . . . . . . . . . . 57
A.5.3. Intereses . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
A.5.4. Modelos, productos de trabajo y modelos de arquitectura 58
A.5.5. Relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
A.5.6. ISO/IEC 19793 Versus ISO/IEC 42010 . . . . . . . . . . . 59
A.5.7. Frameworks de arquitectura y ADLs . . . . . . . . . . . . 60
A.5.8. Archimate . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
A.6. Anexo B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
A.6.1. Guas para puntos de vista de arquitectura . . . . . . . . 61
A.6.2. Guas para puntos de vista de arquitectura . . . . . . . . 62
A.7. Anexo C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
A.7.1. ISO 12207:2008: the software arquitectural desing process
(6.4.3.3.1 y 7.1.3.3.1) . . . . . . . . . . . . . . . . . . . . . 63
Indice de cuadros
2.1. Tipo de frameworks . . . . . . . . . . . . . . . . . . . . . . . . . 15
A.1. Muestra una distribucion de elementos en las plataformas de tal
forma que cumplen la regla ?Regla1?. . . . . . . . . . . . . . . . 58
A.2. Muestra una distribucion de elementos en las plataformas de tal
forma que incumplen la regla ?Regla1?. . . . . . . . . . . . . . . 59
v
vi
INDICE DE CUADROS
Indice de guras
2.1. La diferencia en la interpretacion de un requerimiento. . . . . . . 3
2.2. Comparativa con la Ingeniera Civil. . . . . . . . . . . . . . . . . 4
2.3. Comparativa con la Ingeniera Civil. . . . . . . . . . . . . . . . . 5
2.4. Arquitectura empresarial la base del negocio. . . . . . . . . . . . 5
2.5. Estructura de la arquitectura empresarial. . . . . . . . . . . . . . 6
2.6. Colombianada arquitectonica. . . . . . . . . . . . . . . . . . . . . 9
2.7. Importancia AD. . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.8. Togaf referenciado por archimate. . . . . . . . . . . . . . . . . . . 11
2.9. Componentes de las diferentes vistas de archimate. . . . . . . . . 12
2.10. BMPN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.11. Notaciones del BPMN. . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Rol desempe nado en la empresa . . . . . . . . . . . . . . . . . . . 19
4.2. Conoce que es un Stakeholder . . . . . . . . . . . . . . . . . . . . 19
4.3. Conoce que es un interes en el sistema por parte de un Stakeholder? 20
4.4. En la descripcion de arquitectura identica Stakeholder . . . . . 20
4.5. En la descripcion de la arquitectura (AD) identica los intereses
que los diferentes Stakeholder tiene en el sistema . . . . . . . . . 20
4.6. Elementos de descripcion de arquitectura utiliza? . . . . . . . . . 21
4.7. Etapas del proceso de desarrollo de software realiza la arquitec-
tura de software . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.8. En la descripcion de arquitectura (AD) usted incluye puntos de
vista orientados a expresar el interes que los Stakeholder tienen
en el sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.9. En las vistas que usted crea, utiliza mas de un punto de vista
para expresar los intereses que los Stakeholder tienen en el sistema 22
4.10. Que uso le da a la descripcion de arquitectura . . . . . . . . . . . 23
4.11. Cuales intereses utiliza en los puntos de vista . . . . . . . . . . . 23
4.12. Cuales de los siguientes elementos de descripcion de arquitectura
(AD) utiliza dentro de los puntos de vista . . . . . . . . . . . . . 24
4.13. Que convenciones usa en los puntos de vista . . . . . . . . . . . . 24
4.14. Que uso le da a las convenciones en los puntos de vista . . . . . . 25
4.15. Que tipos de modelo usa en los puntos de vista . . . . . . . . . . 25
vii
viii
INDICE DE FIGURAS
4.16. Que Lenguaje Descripcion de Arquitectura (ADL) utiliza para
describir la arquitectura del sistema . . . . . . . . . . . . . . . . 26
4.17. Que importancia le da a expresar los intereses de los Stakeholder
por medio del ADL? . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.18. Que tipos de modelo expresa con el Lenguaje de Descripcion de
Arquitectura (ADL) utilizado? . . . . . . . . . . . . . . . . . . . 27
4.19. El ADL que utiliza le permite expresar las relaciones y reglas de
relacion entre los elementos de un modelo regido por unos puntos
de vista? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.20. Que Framework de Arquitectura (Marco de Referencia de Arqui-
tectura) utiliza? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.21. El Framework de arquitectura que utiliza le permite identicar
los intereses que los diferentes Stakeholder tienen en el sistema? . 28
4.22. Que relaciones puede identicar con el Framework de arquitectura
que utiliza en los puntos de vista descritos? . . . . . . . . . . . . 29
4.23. El Framework de arquitectura que utiliza le permite declarar re-
glas de correspondencia entre los elementos de los puntos de vista? 29
4.24. Con que propositos usa o ha usado los Framework de Arquitectura? 30
5.1. Proceso para identicacion de Stakeholders . . . . . . . . . . . . 34
5.2. Modelo Organizacional, general a compa nas de TI . . . . . . . . 36
5.3. Funciones de los roles . . . . . . . . . . . . . . . . . . . . . . . . 37
5.4. Cooperacion entre roles para la descripcion de Arquitectura . . . 38
5.5. Cooperacion entre roles para la descripcion de Arquitectura . . . 38
5.6. Proceso descripcion de arquitectura, identicacion Framework,
vista, ADLs, puntos de vista . . . . . . . . . . . . . . . . . . . . . 39
5.7. Identicacion de aplicaciones a construir y a proponer en modelos
de arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.8. Identicacion de ADL de descripcion de arquitectura . . . . . . . 40
5.9. Modelo Archimate Norma ISO/IEEE/IEC 42010 . . . . . . . . . 41
5.10. Modelo Archimate Norma ISO/IEEE/IEC 42010 . . . . . . . . . 42
List of Others
ix
x LIST OF OTHERS
Acknowledgements
Agradecemos por su participacion y colaboracion en la investigacion a:
Participacion directa:
Ing. Alexandra Abuchar (Director)
Ing. Paulo Cesar Coronado (Asesor)
Ing. Sandro Bola nos (Asesor)
Participacion indirecta:
Ing. Agustn Valle Daz
xi
xii ACKNOWLEDGEMENTS
Dedication
Dedicamos este trabajo a Dios y a nuestras familias que con su apoyo in-
condicional nos dieron la fuerza necesaria para mantener las esperanzas a lo
largo de nuestros estudios, llevando la culminacion de esta investigacion y de
este libro.
xiii
xiv DEDICATION
Captulo 1
Introducci on
Con la constante automatizaci on de procesos a traves de herramientas IT,
los sistemas han dado un gran paso hacia el futuro, dado esto, se promueven
nuevas oportunidades para la industria como para la Ingeniera de Software, per-
mitiendo adoptar una norma que permita tener un estandar y/o organizacion,
la cual se adopta a partir del 2001.
La norma ISO/IEC/IEEE 42010 nace el 2 de agosto 2001, cuando ANSI
adopta la norma IEEE 1471 convirtiendola en la ANSI/IEEE 1471 como Practi-
cas recomendadas para descripcion de arquitectura, convertida en norma para
aplicaciones de software. Inicialmente nace como una propuesta para describir
arquitectura, a traves de las necesidades de los Stakeholder, vistas, puntos de
vista y justicacion de la arquitectura [6].
Adoptar mejores practicas para aplicar en la industria se han convertido en
un factor vital, puesto que se incrementa la eciencia y ecacia para el desarrollo
de software, ahora bien, com unmente nos encontramos con diferentes requeri-
mientos, tanto funcionales como no funcionales (atributos de calidad), diferen-
tes Stakeholder, y diferentes tecnologas a utilizar para resolver un problema
especco, esto genera muchas inquietudes de como abordar un proyecto de
arquitectura y aunque tenemos muchos Frameworks arquitectonicos, tampoco
tenemos certeza de cual se debe usar, causando muchas inquietudes a la hora
de abordar un requerimiento; todo este tipo de factores aunque son importan-
tes a la hora de la toma de decisiones no deben convertirse en un problema,
debe abordarse de una manera intuitiva y sencilla, permitiendo que se logre dar
solucion a la verdadera problematica.
La norma aborta la arquitectura de forma holstica, esto quiere decir que no
diferencia entre la descripcion de una arquitectura para una empresa o para un
proyecto. Para los autores esto quiere decir que la norma se aplica tanto para
hacer descripcion de arquitectura de software como empresarial.
1
2 CAP
ITULO 1. INTRODUCCI
ON
Captulo 2
Arquitectura de TI
2.1. Arquitectura de software
La arquitectura de software es importante dado que, esta dene la estruc-
tura del software, as como tambien describe aspectos relevantes de la misma,
entre ellas cualidades sistemicas, y elementos de relevancia, estos pueden ser
llamados Requerimientos no funcionales. Normalmente en la industria encon-
tramos Arquitecturas bien denidas, con todos los elementos necesarios, y dan
bastante claridad acerca de la forma como se debe C onstruir.
o
mplementar una
aplicacion software. En el proceso de desarrollo de software, se le ha dado una
fase donde se debe indicar la forma como se construira la aplicacion, esto pre-
vio a desarrollarla: para comunicar a todos aquellos interesados (Stakeholder)
se requiere que la arquitectura del sistema, sea clara y permita ser entendida
entre todos aquellos involucrados. Es importante la comunicacion entre roles,
normalmente cuando esta comunicacion falla, el sistema, realmente no cumple
las expectativas que se requieren. [12]
Figura 2.1: La diferencia en la interpretacion de un requerimiento Fuente:
http://img.desmotivaciones.es/201011/proyectoinformatico.jpg
3
4 CAP
ITULO 2. ARQUITECTURA DE TI
El problema anterior llevado a un campo de accion mas especco como, lo es
la arquitectura de software, conlleva a problemas estructurales, si la estructura
de un software falla, es posible que todo lo que ella tiene inmerso tambien falle,
ahora bien si requerimos que esa estructura nos soporte una aplicacion con
mas caractersticas, escalabilidad, desempe no, seguridad, entre otras debemos
contemplar que esta a futuro pueda tenerlas, sin que afecte la estructura inicial
para lo cual fue pensada.
Previamente Previamente a la denicion de arquitectura, se requiere identi-
car cuales son las necesidades de los Stakeholder, y de que manera se empieza
a interactuar con el sistema, all nacen los blueprintde arquitectura, donde
se empiezan a dise nar los planos del sistema. El arquitecto de software una vez
identica que es lo que se quiere realizar, empieza a jugar con las piezas del siste-
ma, con el n de unirlas de la manera esperada, siendo este un juego tecnologico,
donde ubicar cada pieza en el lugar correcto corresponde a cierto grado de ex-
pertiz para identicar la forma como debe ponerla, teniendo en cuenta todos
aquellos requerimientos o indicaciones que deben tenerse en cuenta.
Figura 2.2: Comparativa con la Ingeniera Civil Fuente:
http://roble.pntic.mec.es/jdic0020/imagenes/construccion.jpg
Existen elementos que nos ayudan a describir la arquitectura de un sistema,
entre estos elementos se encuentran todos aquellos, que permiten visualizar el
sistema, estos son llamados puntos de vista, y deben estar acordes a quien quiere
visualizar el sistema desde esa misma perspectiva.
Si no se presenta una arquitectura de manera adecuada posiblemente se
encuentren problemas de ambig uedad en el sistema, y se requiere que este eli-
mine todo tipo de ellas, permitiendo a los diferentes Stakeholder que haya un
entendimiento correcto de la aplicacion.
2.2. ARQUITECTURA EMPRESARIAL 5
Figura 2.3: Comparativa con la Ingeniera Civil Fuente: http://www.cnsc8.com/
2.2. Arquitectura empresarial
Es la disciplina de arquitectura aplicada a las empresas, la arquitectura
empresarial busca alinear los objetivos de las empresas con las TIC (tecnologias
de informacion y comunicaciones). [10]
Figura 2.4: Arquitectura empresarial la base del negocio Fuente:
http://www.amazing.com.co/images/arquitectura-de-procesos-de-negocio-big.jpg
La razon de ser del de la arquitectura empresarial es la de aumentar el
valor del negocio por medio de la inversion en TI(Tecnologa de Informacion);
ofreciendo una vision a largo plazo de los procesos, sistemas y tecnologa se
puedan ejecutar y no solo cubrir las necesidades actuales.
6 CAP
ITULO 2. ARQUITECTURA DE TI
Figura 2.5: Estructura de la arquitectura empresarial Fuente:
http://2.bp.blogspot.com
Existen marcos de referencia y metodologas para hacer arquitectura empre-
sarial las cuales ya tienen un nivel alto de madurez y ofrecen conanza en el
mundo empresarial; algunos ejemplos de esto son Togaf, Zachman, FEA, Gar-
ner. En la seccion de framework de arquitectura se estudiara a mas detalle los
frameworks de proposito general y especco.
2.3. Tipos de arquitectos de software
Para denir que es un arquitecto de software, nos basamos en la vision
holstica y ontologica de la nomra ISO/IEC/IEEE 42010. Dicho de otra forma,
un arquitecto de software esta en la capacidad de hacer arquitectura para un
proyecto o para una empresa. Lo anterior depende de la organizacion, de su
negocio, de sus objetivos, de la inuencia del area de sistemas, de la importan-
cia de el/los proyecto/s y del tama no de los mismos. Teniendo en cuenta este
contexto, podemos proponer una serie de niveles en los que un arquitecto de
software se puede desempe nar: [12]
2.3.1. Arquitecto tecnico
Se trata de profesionales con amplios conocimientos tecnicos, conocedor del
negocio de los proyectos y que, probablemente, este asignado a uno o varios
proyectos al mismo tiempo. Algunas de sus responsabilidades suelen ser: denir
los lineamientos de dise no, su arquitectura y demas cuestiones tecnicas de los
proyectos.
2.4. COMPETENCIAS DE UN ARQUITECTO 7
2.3.2. Arquitecto funcional
Tienden a ocupar el rol de team leader y, a su vez, de lder tecnico. Mane-
jan el cronograma y planican las iteraciones junto al project manager (PM).
Suele representar un canal de comunicacion uida entre el PM y los equipos de
desarrollo. Validan dise nos; guan a los desarrolladores, para que cumplan con
las expectativas de calidad tomando metricas, organizando y promoviendo la
documentacion y las buenas practicas; aseguran que el proyecto no se desve de
la arquitectura previamente denida.
2.3.3. Arquitecto Empresarial
Unica los dos casos mencionados anteriormente; pero con algunos agre-
gados. El arquitecto empresarial esta llamado a conocer mas el negocio de la
empresa que un ingeniero de negocio, y debe tener un alto conocimiento en
estrategias de negocio.
2.4. Competencias de un arquitecto
2.4.1. Habilidades humanas
Capacidad de abstraccion creatividad
Liderazgo
Comunicacion oral y escrita
Negociacion
Disciplina
Autodidacta
[4]
2.4.2. Habilidades tecnicas
Manejar por lo menos un ADL (lenguaje de descripcion de arquitectura)
y el uso de por lo menos una herramienta de modelado.
Analisis, Dise no y Programacion Orientada a Objetos.
Estar actualizado en los paradigmas programacion que esten con fuerza
en el mercado.
Ventajas, desventajas y particularidades entre los principales lenguajes y
tecnologas disponibles: Java, C++, .Net, J2EE, etc.
Bases de datos.
8 CAP
ITULO 2. ARQUITECTURA DE TI
Desarrollo basado en componentes.
Patrones de dise no.
Patrones de arquitectura.
Estilos de arquitectura.
Frameworks (De arquitectura y desarrollo).
Nuevas tecnologas y plataformas, incluyendo open source.
Conocimientos del hardware y sus capacidades.
Metodos de desarrollo de software tales como el Proceso Unicado, Scrum
y Xp por nombrar algunos
[4]
2.5. Importancia de la descripcion de arquitec-
tura
Es insolito darnos cuenta como podemos obtener dise nos de un hotel que
lleva construido por lo menos unos 50 a nos, pero no tenemos la arquitectura
del software hecho hace 6 meses; la falta de documentacion en los proyectos de
software no es algo nuevo ni que impresione, pero s que nos debera preocupar,
aqu se encuentra la base para la mantenibilidad y el exito de estos proyectos
en el tiempo. [1]
Todos los proyectos de Tecnologas de la informacion que conlleven software
tienen arquitectura. En los tiempos modernos la arquitectura se viene prac-
ticando como un arte a base de dibujos compuestos de cajas y echas, pero
como todo en este mundo de la tecnologa tiene un ritmo frenetico a la hora de
evolucionar, ya no basta con pintar y plasmar en papeles como va a funcionar
nuestra estructura. En proyectos grandes y con diferentes necesidades, necesi-
tamos contemplar diferentes puntos de vista para diferentes grupos de personas
(Stakeholder) de forma que todos entiendan lo que se quiere hacer, lo que se
esta haciendo y muy importante lo que se hizo. [7]
Lo que busca la descripcion de la arquitectura es tener una documentacion de
la estructura que sea duradera, rigurosa, completa y util. Con el n de mejorar
la comunicacion y el entendimiento entre los diferentes Stakeholder, ayudar a
corregir el problema de la desorganizacion de los proyectos, la dicultad de
la mantenibilidad, tener evidencia de las decisiones tomadas y de paso validar
buenas practicas a la hora de realizar una arquitectura. [9]
2.6. DISE
NO DE ARQUITECTURA 9
Figura 2.6: Colombianada arquitectonica Fuente:
http://i1185.photobucket.com/albums/z352/thereivaj/colom
2.6. Dise no de arquitectura
El nivel de detalle que se puede dar para una arquitectura es proporcionado
seg un para quien sea esta destinado, esto con el n de brindar a dicha persona
o grupo de personas la forma mas propicia para entender la arquitectura del
sistema, catalogando as de esta manera la arquitectura como dos tipos (dise no
de alto nivel y dise no de bajo nivel) las cuales ayudaran a entender un poco mas
la forma como debe construirse el sistema.
2.6.1. Dise no de alto nivel
Un dise no de alto nivel corresponde a la forma como se aborda el sistema des-
de un punto de vista mas abstracto, sin dar detalles concretos o muy puntuales
sobre la construccion del sistema.
2.6.2. Dise no de bajo nivel
Para un dise no de bajo nivel se debe llegar a una aproximacion de la imple-
mentacion del sistema, incluyendo todos aquellos aspectos detallados del siste-
ma, siendo este dise no el q tenga mayor claridad y acercamiento a la construccion
del sistema. Este tipo de dise nos son necesarios en cuanto a que pueden ser utiles
para un grupo de desarrollo, evitando as ambig uedades que puedan presentarse
sobre el sistema. [9]
10 CAP
ITULO 2. ARQUITECTURA DE TI
Figura 2.7: Importancia de la descripcion de la arquitectura Fuente:
http://blog.construmatica.com/wp-content/uploads/2011/03/AGI-4.jpg
2.7. Lenguajes de descripcion de arquitectura
(ALDs)
2.7.1. UML
El lenguaje UML comenzo a gestarse en octubre de 1994 [1], cuando Rum-
baugh se unio a la compa na Rational fundada por Booch (dos reputados in-
vestigadores en el area de metodologa del software). El objetivo de ambos era
unicar dos metodos que haban desarrollado: el metodo Booch y el OMT (Ob-
ject Modelling Tool). El primer borrador aparecio en octubre de 1995. En esa
misma epoca otro reputado investigador, Jacobson, se unio a Rational y se in-
cluyeron ideas suyas. Estas tres personas son conocidas como los tres amigos.
Ademas, este lenguaje se abrio a la colaboracion de otras empresas para que
aportaran sus ideas. Todas estas colaboraciones condujeron a la denicion de la
primera version de UML [2]. UML se encuentra avalado por la OMG 1, permi-
tiendo que este sea convertido en un estandar a nivel internacional.
Con la necesidad de crear un estandar para la comunicacion entre dise nadores
de software, surge UML, el cual se encarga de estandarizar los dise nos para
que estos puedan ser entendibles para cualquier dise nador, permitiendo una
mejor comunicacion entre ellos. La fase mas importante donde se hace uso de
estos modelos realizados en UML es en la de dise no, esto es necesario para que
los grupos de desarrollo puedan entender las caractersticas del sistema entre
muchos otros detalles que se deben tener en cuenta.
UML como cualquier lenguaje dene un vocabulario y unas reglas para per-
mitir la comunicacion, siendo dicho vocabulario, los elementos de comunicacion,
y las reglas, la sintaxis de dicho lenguaje, esto con el n de que este no pueda
presentar ambig uedades, de la forma como debe ser representado para que sea
entendible para todos los que quieran comunicarse mediante este ADL.
2.7. LENGUAJES DE DESCRIPCI
ON DE ARQUITECTURA (ALDS) 11
Para que un modelo UML se encuentre con una buen nivel de completitud
este debe contemplar
Elementos, los cuales corresponden a aquellas abstracciones de un elemen-
to de la vida real.
Relaciones, la relacion que puede existir entre los elementos anteriores.
Diagramas, Esto es una agrupacion de todos aquellos elementos son todas
las posibles interrelaciones.
[3]
2.7.2. SysML
SysML es un lenguaje, para modelado de sistemas, nace en el 19 de septiem-
bre de 2007 como una propuesta para el OMG, permitiendo modelar Analisis,
y dise no. [11]
2.7.3. ARCHIMATE
Archimate es un lenguaje libre e independiente para modelar arquitectura
empresarial. su objetivo es describir de una forma clara los dominios del nego-
cio. archimate es una tecnologia estandar del open group y esta basada en la
conceptos del estandar ISO 1471. archimate tambien es una marca registrada
por Open Group.
El lenguaje de modelacion de archimate se diferencia de otros como UML y
BPMN por tener un meta-modelo bien denido y por ofrecer un amplio margen
para el modelaje de la empresa.Archimate soporta framework como TOGAF,
DYA y la FAI, archimate es un est andar abierto mantenido por el Open Group.
[4]
Figura 2.8: Togaf referenciado por archimate Fuente: http://blog.itil.org
En la mayora de las empresas los grupos tecnicos y los grupos de negocio
hablan diferentes idiomas, dise nan sus propios modelos y tienen sus propias
tecnicas y herramientas por lo que se torna difcil la comunicacion y el entendi-
miento entre estas partes, afectando el desarrollo del negocio.
12 CAP
ITULO 2. ARQUITECTURA DE TI
Archimate ofrece un lenguaje com un para describir la construccion y ope-
racion de procesos de negocio, estructuras organizativas, ujos de informacion,
sistemas informaticos e infraestructura tecnica. De esta forma se facilita la in-
teraccion, el dise no, informar el impacto de las decisiones y cambio dentro de
los diferentes grupos del negocio.
ArchiMate evita la confusion, ofreciendo un lenguaje sencillo y uniforme
para describir la arquitectura de la empresa. ArchiMate entrega tres capas de
modelaje:
La capa de negocio: procesos de negocio, organizacion, funciones de negocios,
productos y servicios de ocina.
La capa de aplicacion: aplicaciones, servicios de aplicacion, las funciones de
aplicacion, interfaces de aplicaciones.
La capa de la tecnologa: nodos, redes, servicios de infraestructura, software.
Figura 2.9: Componentes de las diferentes vistas de archimate Fuen-
te: https://lh4.ggpht.com/i5lh67xNYlZqKNb6eJD7yyK9UHkglyg7iP4Ogw4j3ZngVYkhslz0LBOi-
BjssMJJxoJKtA=s139
2.7.4. BPMN
BPMN es un lenguaje de descripcion de arquitectura orientado a describir
detalladamente los diferentes procesos de negocio de una empresa.
La rapida evolucion La rapida evolucion y de los negocios necesita el uso de
estandares para asegurar el entendimiento entre diferentes area y departamentos
dentro de una empresa y tambien con empresas diferentes. BPMN ofrece un
amplio conjunto de anotaciones que aseguran el cubrimiento de los diversos
procesos que ocurren dentro de una institucion.
2.8. FRAMEWORKS DE ARQUITECTURA 13
Figura 2.10: BMPN Fuente: https://lh6.ggpht.com
El objetivo del BPMN es asegurar la eciencia y el desarrollo de los proce-
sos en el tiempo a traves de la gestion de los procesos de negocio, que se deben
modelar, organizar, documentar y optimizar de forma continua
Figura 2.11: Notaciones del BPMN
[2]
2.8. Frameworks de arquitectura
Un Frameworks de arquitectura es una estructura de soporte en la cual la
descripcion de arquitectura, bien sea de un proyecto de desarrollo (Arquitectura
de software) o de una empresa (Arquitectura empresarial), puede ser organiza-
da y encarada con mayor simplicidad. Un Frameworks establece convenciones,
principios y practicas comunes, con un dominio de aplicacion y/o comunidad de
Stakeholder.
Los usos de un Frameworks de arquitectura incluyen pero no se limitan a:
La creacion y/o analisis de la descripcion de arquitectura, entendiendo
14 CAP
ITULO 2. ARQUITECTURA DE TI
esta como un producto tangible y entregarse resultado de un trabajo o
proceso (workProduct), siendo este uno de los usos mas populares que se
encuentra en la industria del software colombiana.
Desarrollo de herramientas de modelado de arquitectura.
Metodos de arquitectura.
Establecer procesos para facilitar la comunicacion.
Un Frameworks de arquitectura debe incluir :
Informacion identicando el Frameworks de arquitectura
La identicacion de uno o mas intereses
La identicacion de uno o mas Stakeholder que tienen esos interes
Uno o mas puntos de vistas que muestran esos interes
Cualquier regla de correspondencia
Un Frameworks de arquitectura debera incluir condiciones de aplicabilidad.
Ejemplos:
Una descripcion de arquitectura (AD) usando un Frameworks de arqui-
tectura (AF) necesita identicar Stakeholder determinados que operan en
una jurisdiccion especca.
Una descripcion de arquitectura (AD) usando un Frameworks de arquitec-
tura (AF) puede omitir un punto de vista especicado cuando un interes
en particular no esta identicado
Usando un Frameworks de arquitectura (AF), un tipo de modelo, MK por
sus siglas en ingles puede ser omitido en un punto de vista determinado
para un Stakeholder especico
Algunos ejemplos de Frameworks de arquitectura son:
Zacman
MODAF (UK ministery defensy)
TOGAF
Kruchten (4+1)
Siemens 4
RM-ODP (ISO/IEC 10746)
GERAM (ISO 15704)
2.8. FRAMEWORKS DE ARQUITECTURA 15
2.8.1. Frameworks de proposito general -
Lo que diferencia a este tipo de Frameworks con respecto a otros, es que
tratan de resolver el problema general que las empresas estan teniendo. Estos
marcos son agnosticos a cualquier aplicacion especca. Ellos no tienen factores
especcos de negocio (empresa especca), sino mas bien son basados capacidad.
Estos marcos son generalmente impulsados por consorcios industriales como
Open Group. Como caracterastica principal, estos brindan un mayor nivel de
personalizacion con respecto a los de dominio especco
Entrega deniciones abiertas a traves de taxonomas y ontologas
Indiferente a la estructura de la organizacion
Indiferente a los procesos de bajo nivel (SDLC, PMO, Service Manage-
ment, etc )
Muy congurable a la empresa
2.8.2. Frameworks de dominio especco -
Estos Frameworks que se derivan de un esfuerzo de arquitectura empresarial
para un dominio especco. Estos marcos se obtuvieron a partir de un conjunto
predenido de intereses de un negocio especco en mente, ya que proceden de
una ocina de arquitectura empresarial o del esfuerzo de mejora de procesos de
un gobierno o de una empresa. En gran parte de estos marcos son impulsados por
las agencias gubernamentales como el gobierno de los EE.UU. u otras geografas.
Como caracterstica principal, estos brindan una mayor especicacion en guas
predenidas a seguir con respecto a los de proposito general
Guas prescriptivas para (estructura de la organizacion, procesos y arte-
factos)
Por lo general, ofrecen muchas plantillas
Muchos ejemplos del mundo real
Referencias [12] [8][5]
2.8.3. Tipicaci on de frameworks
Cuadro 2.1: Tipo de frameworks
Frameworks de proposito general Frameworks de dominio especco
TOGAF FEAF
Agile EA DODAF
Zachman MODAF
(TEAF)
16 CAP
ITULO 2. ARQUITECTURA DE TI
Captulo 3
Descripcion ISO/IEC/IEEE
42010
La conformidad de la norma se dene bajo los siguientes aspectos:
Descripcion de arquitectura.
Artefacto, usado para describir una arquitectura.
Framework de arquitectura.
Convenciones, principios y practicas para descripcion de una arquitectura,
establecidos con un dominio de aplicacion y/o comunidad de Stakeholders.
Lenguajes de descripcion de arquitectura. Un ADL debe especicar :
La identicacion de 1 o mas interes a ser expresadas por ADL
La identicacion de 1 o mas Stakeholders que tiene esos interes
Tipos de modelos implementados por el ADL, los cuales muestran
los interes
Cualquier punto de vista
Un ADL no necesita proveer ning un punto de vista, este puede denir 1 o
mas tipos de modelo para usar en cualquier punto de vista que se dena.
Un ADL necesita proveer reglas de relacion relativos a los tipos de modelos
Puntos de vista de arquitectura.
Artefacto que establece las convenciones para la construccion, interpreta-
cion, y uso de vistas para presentar un interes especco del sistema.
[6]
17
18 CAP
ITULO 3. DESCRIPCI
ON ISO/IEC/IEEE 42010
Captulo 4
Situaci on actual de las
empresas bogotanas
La encuesta tuvo un total de 21 encuestados:
Figura 4.1: Rol desempe nado en la empresa
Se evidencia que la poblacion en su mayora son desarrolladores, pero lo mas
importante es que se tiene una poblacion diversa de Stakeholder.
Figura 4.2: Conoce que es un Stakeholder
19
20CAP
ITULO 4. SITUACI
ITULO 4. SITUACI
ITULO 4. SITUACI
ITULO 4. SITUACI
ITULO 4. SITUACI
ITULO 4. SITUACI
ONDE UNAARQUITECTURABASADAENLANORMAISO/IEC/IEEE-42010
5.1. Modelos para la descripcion de una arqui-
tectura basada en la norma ISO/IEC/IEEE-
42010
Con la constante automatizacion de procesos a traves de herramientas de las
Tecnologias de informacion (IT), los sistemas han dado un gran paso hacia el
futuro, dado esto, se promueven nuevas oportunidades para la industria como
para la Ingeniera de Software, permitiendo adoptar una norma que permita
tener un estandar y/u organizacion, la cual se adopta a partir del 2001.
La norma ISO/IEC/IEEE 42010 nace el 2 de agosto 2001, cuando ANSI
adopta la norma IEEE 1471 convirtiendola en la ANSI/IEEE 1471 como practi-
cas recomendadas para descripcion de arquitectura, convertida en norma para
sistemas software.Inicialmente nace como una propuesta para describir arqui-
tectura, a traves de las necesidades de los stakeholder, vistas, puntos de vista y
justicacion de la arquitectura.
Adoptar mejores practicas para aplicar en la industria se han convertido en
un factor vital, puesto que se incrementa la eciencia y ecacia para el desarrollo
de software, ahora bien, com unmente se encuentra con diferentes requerimien-
tos, tanto funcionales como no funcionales (atributos de calidad), diferentes Sta-
keholder, y diferentes tecnologas a utilizar para resolver un problema especco,
esto genera muchas inquietudes de como abordar un proyecto de arquitectura
y aunque se tienen muchos frameworks arquitectonicos, tampoco hay certeza
de cual se debe usar, causando muchas inquietudes a la hora de abordar un
requerimiento; todo este tipo de factores aunque son importantes a la hora de la
toma de decisiones no deben convertirse en un problema, debe abordarse de una
manera intuitiva y sencilla, permitiendo que se logre dar solucion a la verdadera
problematica.
Entrando en la norma ISO/IEC/42010, esta apoya la toma de decisiones en
la arquitectura, la norma presenta una postura holistica a la hora de hablar
de la arquitectura, permitiendo identicar cuales serian aquellos factores que
permiten denir la forma como se abordara la arquitectura, en este tipo de
proyectos. El lenguaje que se debe hablar debe ser com un entre los diferentes
stakeholder del proyecto, permitiendo una mejor comunicacion en los proyectos.
Para entender mejor la norma ISO/IEC/IEEE 42010, el artculo presenta la
decripcion, conclusiones y trabajos futuros, que permiten entender un poco mas
acerca de este tema y la aplicabilidad que tiene en el campo de la arquitectura
de software.
5.2. Descripcion de la norma ISO/IEC/IEEE-
42010
La arquitectura de software, se apoya en elementos fundamentales con el n
de que esta pueda ser descrita, esto comunmente es llamado descripcion de
arquitectura, para tener un estandar internacional, ISO denio una norma
5.2. DESCRIPCI
ON DE LA NORMA ISO/IEC/IEEE-42010 33
correspondiente a identicar todos aquellos aspectos que deben ser tenidos en
cuenta, a la hora de elaborar una descripcion de arquitectura.
Dentro de los elementos que deben tenerse en cuenta para la descripcion
de arquitectura se encuentran estilos arquitectonicos, frameworks, patrones ar-
quitectura, diagramas, notaciones, elementos, restricciones de dise no las cuales
son fundamentales para describir o elaborar la estructura de un sistema; la ar-
quitectura debe ser representada o escrita en los terminos en los que desea ser
explicada, aquello que es parte de ella y la forma como se relaciona con otras
arquitecturas, este estandar internacional permite denir la forma como se des-
cribe la arquitectura, indicando 4 puntos de conformidad dentro de ella, estos
son: descripcion de arquitectura, puntos de vista, framework de arquitectura y
lenguaje de descripcion de arquitectura, estos puntos son necesarios a la hora
de abordar un proyecto de software y denir la arquitectura.
Constantemente los arquitectos se encuentran con decisiones de dise no que
impactaran el sistema, no obstante se debe tomar la decision correcta para
describir la arquitectura, y esto es importante dado que no se puede cambiar
constantemente la arquitectura.
Cada requerimiento, necesita un analisis respectivo, esto es: Identinticar
los intereses que tienen los stakeholder sobre el sistema, vericar si existe un
framework de arquitectura, en cuantas vistas deberia describirse el sistema las
cuales son gobernadas por los puntos de vista, adicionalmente las reglas de
correspondencia o restricciones que se deben tener en cuenta para la elaboracion.
Al hacerse un uso indebido de la descripcion de arquitectura, implica que
se represente incorrectamente el sistema, haciendo que este sea poco entendible
para los diferentes stakeholder, adicional a ello se convierte en un factor para la
mala comunicacion entre los diferentes involucrados (Analistas, Desarrolladores,
Arquitectos, Tester) causando problemas mas grandes con respecto al proceso
de desarrollo de Software.
Para brindar mecanismos de comunicacion correctos en los proyectos de soft-
ware, se hace necesario utilizar un lenguaje, este es determinante para establecer
la comunicacion entre los diferentes stakeholder; para ello se debe identicar cual
lenguaje contiene todos los elementos necesarios para una correcta descripcion
de la arquitectura, entre ellos existen UML, Archimate, Rapide, SysMl, BPMN,
entre otros, los lenguajes anteriores permiten una correcta comunicacion entre
los diferentes stakeholder. La iconograa y la relacion que pueden existir entre
ellos permite representar un sistema, dandole estructura, y caracterizacion de la
forma como debe construirse, esto corresponde a la descripcion de arquitectura
que a su vez cubre las necesidades de un grupo de Stakeholders.
Com unmente se encuentra en algunos dise nos o interpretaciones que aunque
se vean atractivos y agradables, no signica que estos describan correctamente
una arquitectura, dado que no se usa un lenguaje de descripcion de arquitectura
(ADL), para que este sea considerado un modelo se hace necesario que cumpla
con unas especicaciones y restricciones establecidas en un tipo de modelo,
el cual debe pertenecer a un ADL especico, cuando sucede lo mencionado
34CAP
ONDE UNAARQUITECTURABASADAENLANORMAISO/IEC/IEEE-42010
anterirormente, corresponde a un ADL especicado por la persona que creo el
modelo.Para que un tipo de modelo sea considerado como tal se deben tener en
cuenta los siguientes elementos: Entidades,Atributos, Relaciones, Restricciones.
Para que un ADL sea considerado como tal se deben tener en cuenta los
siguientes elementos: especicar la identicacion de los intereses en el siste-
ma,Tipos de modelo, Puntos de Vista
En la descripcion de arquitectura se deben contemplar vistas, las cuales
permiten denir un contexto de interpretacion que normalmente tiene cabida
dentro de uno de los intereses de los stakeholder, por ejemplo: cuando se requiere
que funcionalmente se entienda su estructura, se debe contemplar una vista que
represente las funciones del sistema, y para ello se debe tomar una vista que
represente dicho interes.
5.3. Modelos Propuestos
Con la nalidad de darle una interpretacion, a la norma ISO/IEC/IEEE-
42010 y ver la aplicabilidad de la arquitectura, se proponen los siguientes mode-
los que permiten entender mejor la forma como debe describirse la arquitectura,
as como entender el proposito y nalidad que esta representa.
Basados en la norma ISO/IEC/IEEE-42010, para el proceso de descripcion
de arquitectura se hace necesario identicar los Stakeholders, un ejemplo de estos
son: Usuario Final, Arquitectos, Gerentes de Proyecto, Gerente Operacional,
Desarrolladores entre otros multiples roles que pueden intervenir en desiciones
de arquitectura. Se debe tener en cuenta que para cada proyecto de arquitectura,
se deben identicar aquellos involucrados al igual que sus puntos de vista sobre
el sistema, esto dado que es requerido identicar aquellas necesidades relevantes
del proyecto.
Figura 5.1: Proceso para identicacion de Stakeholders
A traves del anterior diagrama de procesos se le brinda al arquitecto la forma
en la cual puede identicar los stakeholder y todo lo que esta inmerso en ellos,
5.3. MODELOS PROPUESTOS 35
con el n de poder aplicar de una forma correcta la arquitectura, seg un la norma
ISO/IEC/IEEE 42010.
Architect: Arquitecto Empresarial/Software, que se encuentra implicado
en el proyecto, y requiere describir la arquitectura seg un corresponda su
rol, o funciones especicas.
Identify Project: Ubicacion espacial, nombre de proyecto, objetivos del
mismo.
Ask for information the organizational viewpointpoint: Identicar
todos los elementos para construir un diagrama organizacional, que per-
mita ubicar casos de escalamiento, al igual que responsables por cada uno
de los temas a realizar dentro del proyecto.
Identify Expectations: Identicar, las expectativas de los involucrados
del proyecto, identicar que requieren ellos realizar para as identicar cual
sera la mejor forma de representarlo.
Prioritize the Importance of Stakeholder: Permite darle la impor-
tancia a cada uno de los Stakeholder, esto con el n de saber si su criterio
se hace importante para la descripcion de arquitectura, estos pueden ser
de dos niveles:
Stakeholder First Level: Son aquellos que tienen relevancia, a la
construccion de la arquitectura.
Stakeholder Second Level: Son aquellos Stakeholder que se hacen
importantes para la descripcion de la arquitectura, sin embargo debe vali-
darse si con los Stakeholder de primer nivel se hace necesario la inclusion
de este Stakeholder como importante, al igual que su criterio.
En el diagrama anterior se identica una actividad como Organizational
Viewpoint, esta actividad corresponde a realizar un diagrama de la organiza-
cion para la cual se realiza la descripcion de arquitectura, esto normalmente
corresponde a un grupo de Stakeholder, con sus respectivos cargos dentro de
la organizacion. Las estructuras de las empresas de TI, normalmente encajan
dentro del siguiente modelo Organizacional:
Project Manager: Corresponde a todos aquellos responsables del pro-
yecto, la direccion del proyecto se encuentra dentro de este Stakeholder.
Las organizaciones contienen dos grandes areas, las cuales corresponden a
la Tecnica y a la Funcional:
Technical: Corresponde a la parte encargada de orientar a la organizacion
con todos los elementos tecnologicos para apoyar los procesos organizacio-
nales, automatizacion y apoyo a la gestion de la informacion a traves de
Software.
36CAP
ONDE UNAARQUITECTURABASADAENLANORMAISO/IEC/IEEE-42010
Functional: Corresponde a la parte encargada de orientar correctamente
el funcionamiento de los procesos organizacionales, al igual que conocer
correctamente el negocio e identicar todos aquellos elementos que apoyan
a la misma para ir de la mano con los objetivos estrategicos de la compa na.
Architecture: Este corresponde a un arquitecto de negocio, que se en-
carga de apoyar los procesos y mejoras de los mismos en el area funcional,
tambien puede ser un arquitecto empresarial.
Developer: Corresponde a una persona o grupo de personas que se encar-
gan de realizar la Construccion del Software Requerido por la Compa na.
Analist: Corresponde a aquellos Stakeholder que conocen las funciones
del negocio al igual que la forma como debe ser representado.
Quality Analist: Son los Stakeholder encargados de asegurar la ca-
lidad del producto.
Requirements: Son aquellos Stakeholder que realizan y apoyan el
entendimiento de los requerimientos de negocio, a nivel funcional.
Figura 5.2: Modelo Organizacional, general a compa nas de TI
Para entender un poco mas cual es la forma como dichos se debe representar
los intereses de los anteriores Stakeholder sobre el sistema se identica a detalle
los roles de los mismos permitiendo entender como operan en la descripcion de
arquitectura (AD).
5.3. MODELOS PROPUESTOS 37
Figura 5.3: Funciones de los roles
La forma como se relacionan los diferentes Stakeholder con el n de describir
correctamente la arquitectura se identica de la siguiente manera:
38CAP
ONDE UNAARQUITECTURABASADAENLANORMAISO/IEC/IEEE-42010
Figura 5.4: Cooperacion entre roles para la descripcion de Arquitectura
El area funcional, coopera con el area tecnica, realizando levantamiento
de requerimientos, esto se transmite en casos de uso de las funcionalidades,
o procesos de negocio, apoyando al rol de arquitectura, para identicacion de
algunos intereses de los stakeholder.
Para identicar todos aquellos intereses de los Stakeholder que se identica-
ron en el proceso anterior (graca.2) se debe realizar el proceso de identicacion
de intereses de estos sobre el sistema, para ello se proporciona el siguiente pro-
ceso:
Figura 5.5: Cooperacion entre roles para la descripcion de Arquitectura
5.3. MODELOS PROPUESTOS 39
Funcionalidad: Capacidad del producto software para proporcionar fun-
ciones que satisfagan las necesidades especicadas e implcitas.
Fiabilidad: capacidad del producto software para mantener un nivel espe-
cicado de rendimiento.
Usabilidad: la capacidad del producto software de ser entendido, aprendido,
utilizado y atractivo al usuario.
Eciencia: la capacidad del producto software para proporcionar el rendi-
miento apropiado, relativo a la cantidad de recursos utilizados.
Mantenibilidad: la capacidad del producto software para ser modicado.
Las modicaciones pueden incluir correcciones, mejoras o adaptacion del softwa-
re a cambios en el entorno, en los requisitos o en las especicaciones funcionales.
Portabilidad: la capacidad del producto software de ser transferido de un
entorno a otro.
Para describir correctamente la norma ISO/IEC/IEEE42010, proponemos el
siguiente diagrama de procesos, de la vista de negocio de archimate. Donde el
arquitecto debe realizar los siguientes pasos:
Figura 5.6: Proceso descripcion de arquitectura, identicacion Framework, vista,
ADLs, puntos de vista
Identicar Framework: Esto corresponde, a la tarea de vericar cual co-
rresponde al framework que mas se acomoda a las necesidades de los stakeholder
identicadas en el proceso 1.1, este debe cumplir especcamente la forma como
debe describirse la arquitectura.
40CAP
ONDE UNAARQUITECTURABASADAENLANORMAISO/IEC/IEEE-42010
Figura 5.7: Identicacion de aplicaciones a construir y a proponer en modelos
de arquitectura
Proponer vistas: Esto corresponde, a la tarea de proponer o identicar las
vistas necesarias que suplen la descripcion de arquitectura, esto corresponde a
proponer cuales utilizar de un framework. Identicar ADLs: Esto corresponde,
a identicar el lenguaje para la descripcion de arquitectura.
Figura 5.8: Identicacion de ADL de descripcion de arquitectura
Identicar Puntos de Vista: Es necesario identicar los puntos de vista, estos
estan limitados al lenguaje, permitiendo hacer uso de uno o muchos puntos de
vista para describir la arquitectura.
El arquitecto debe apoyarse en diferentes elementos que le permiten en la
descripcion de arquitectura ser identicadas, con el n de usarlas o integrarlas
con el sistema a describir.
5.3. MODELOS PROPUESTOS 41
Figura 5.9: Modelo Archimate Norma ISO/IEEE/IEC 42010
En la descripcion de arquitectura, es necesario identicar todos aquellos ele-
mentos que se deben describir concretamente en la arquitectura, este correspon-
de a arquitectura de software o arquitectura empresarial, en los cuales se debe
describir la aplicacion como debe construirse, esto es representado con puntos
de vista especcos de un ADL.
Todo lo mencionado anteriormente se deduce en el modelo propuesto en la
gura 10:
42CAP
ONDE UNAARQUITECTURABASADAENLANORMAISO/IEC/IEEE-42010
Figura 5.10: Modelo Archimate Norma ISO/IEEE/IEC 42010
5.4. Trabajo Por Realizar
Realizacion de un gu
ON 45
Stakeholders
Individuo, equipo y/u organizaciones o clases de estos que tengan un interes
en el sistema.
A.1.2. Conceptos encontrados en la norma
Sistema
Sera entendido como es descrito en la norma ISO/IEC 15288.
Sistemas que son construidos por hombres y que pueden ser
congurados con uno o mas de los siguientes: hardware, software,
datos, humanos, procesos, (ej. proveer servicios al usuario),
procedimientos (ej. instrucciones del operador), facilidades,
materiales y entidades que ocurren naturalmente.
Productos de software y servicios
Como se describen en ISO 12207
Aplicaciones de software
Como se describe en ISO 1471:2000
C ualquier sistema donde el software constituya inuencia esencial
en el dise no, construccion, despliegue y evolucion del sistema de
manera holstica (como un todo); para abarcar aplicaciones
individuales, sistemas en el sentido tradicional, subsistemas,
sistemas de sistemas, lneas de producto, familias de productos,
toda empresa, y otras agregaciones de interes
Como se indica en la ISO 15288:2008. Un sistema es una combinacion de
interacciones entre elementos organizados para lograr un proposito.
Un sistema esta situado en un entorno. El entorno determina la totalidad de
l inuencia sobre el sistema durante el ciclo de vida, incluyendo las interacciones
con el entorno. El entorno de un sistema puede contener otros sistemas.
Para propositos de la norma el entorno es limitado por y entendido a traves
de la identicacion de los Stakeholders y sus intereses.
la arquitectura de un sistema indica que es esencial con respecto al sistema
considerado en relacion a un entorno. La caracterizacion de un sistema puede
pertenecer a:
elementos del sistema
como estan organizados e interrelacionados estos elementos
principios de la organizacion y/o dise no del sistema
principios de gobernabilidad e la evolucion en el ciclo de vida del sistema
46 AP
ON 47
en terminos de esta norma la arquitectura de un sistema es holostica. en vez de
eso se usan frases como vista de negocio vista fsica vista tecnica.
Descripcion de arquitectura elementos y correspondencia
Son las mnimas unidades de actividades en el estandar y son cualquier
construido en una excepcion de arquitectura.
Todo eStakeholder, intereses, puntos de vista, vista, tipo de modelo, modelo,
decision y justicacion de arquitecturas son consideradas elementos de arquitec-
tura.
cuando dos puntos de vista y tipos de modelo son denidos y esto son
llenados es decir completados, los elementos de descripcion de arquitectura
son introducidos.
una correspondencia dene la relacion entre elemento denicion de arqui-
tectura. una correspondencia es usada para expresar relaciones de arqui-
tectura de los intereses en una exposicion de arquitectura oltre descrip-
ciones de arquitecturas.
las correspondencias puede ser gobernada por reglas de correspondencia
ejemplos de composicion consecuencia trazabilidad dependencia restric-
cion y obligatoriedad.
decisiones de arquitectura justicacion
Justicacion de las necesidades tomadas pueden incluir la base para la
decision alternativas y consecuencias consideradas si t? has anyone de
fuentes join formacion adicional.
decisiones penitentes a los intereses.
una decision puede afectar la arquitectura en diferentes aspectos se pueden
reejar en descripcion de arquitectura como:
requiriendo las existencias de elementos que es pura.
combinando las propiedades del mp version de arquitectura.
disparadores de analisis de negocio en relacion algunos elementos de
arquitectura coma incluyendo otras decisiones e intereses son revisados
levantamiento de nuevos intereses.
arquitectura en el ciclo de vida
La arquitectura contribuye al desarrollo y operacion y mantenimiento desde
la concepcion inicial hasta la puesta en uso. arquitectura toma lugar en el con-
texto y el proyecto u organizacion. arquitectura ejercida sobre todo y no solo en
una etapa del ciclo de vida . denicion de arquitectura el producto resultado de
48 AP
ON 49
como soporte a la planeacion del sistema la programacion y presupuesta-
cion.
establecer criterios de aceptacion para la especicacion de implementacion
de una arquitectura.
como mecanismos de adaptacion para externos y proyectos o polticas
internas de la organizacion ejemplo legislacion principios generales de ar-
quitectura.
bases para la revisin analisis y evaluacion de sistemas entre su ciclo de
vida.
bases para el analisis y evaluacion de arquitecturas alternativas.
compartir lecciones aprendidas y revisar conocimientos de arquitectura
como puntos de vista patrones y estilos.
entrenamiento y educacion de Stakeholders y otras partes sobre mejores
practicas en arquitectura y evaluacion del sistema.
Frameworks de arquitectura y ADLs
Son mecanismos muy usados en arquitectura un framework de arquitectura
establece practicas comunes para la creacion e interpretacion analisis y uso de
have con un dominio particular de aplicacion o comunidad estoy soltera
Los usos de framework de arquitectura incluyen pero no se limitan creacion
de la descripcion de la arquitectura.
Desarrollo de herramientas de modelado de arquitectura y metodos de ar-
quitectura y establecer procesos para facilitar la comunicacion compromisos de
interpretacion a traves de m ultiples proyectos y/o organizacion ejemplos:
Zacman
MODAF (UK ministery defensy)
TOGAF
Kruchten (4+1)
Siemens 4
RM-ODP
ISO/IEC 10746
ISO 15704
50 AP
ON DE LA ARQUITECTURA 51
contexto
glosario
informacion de control de versiones
administracion de la conguracion
referencias
Los resultados de cualquier evaluacion de arquitectura o descripcion de ar-
quitectura deben ser incluidos
la norma no describe:
La granuladad de intereses
como los intereses se interrelacionan con otros interees
Relacionar un interesa otras declaraciones del sistema como : las nece-
sidades de los Stakeholders, los objetivos del sistema, los objetivos del
sistema o requerimientos del sistema. Esto es tema de los frameworks de
arquitectura, metodos de arquitectura y otras practicas y otras practicas
Puntos de vista de arquitectura
Una AD debe incluir cada punto de vista usado.
Cada interes identicado se debe mostrar por lo menos en un punto de vista
A.2.3. Vistas de arquitectura
Una AD debe incluir exactamente una vista por cada punto de vista usado
Cada vista se debe adherir a las convenciones que la gobiernan por el punto de
vista Cada vista debe incluir:
identicar y entregar informacion especca para el proyecto y/o organi-
zacion
Identicar el punto de vista que la gobierna
Modelos de arquietctura que direccionan todos los interesas mostrados por
le punto de vista que la gobirna y cubirr el sistemaamcaldo de ese punto
de vista
Registrar todos los pendientes de una vista con respecto al punto de vista
que la gobierna
52 AP
ON DE LA ARQUITECTURA 53
A.2.5. Modelos de arquitectura
Una vista debe estar compuesta por 1 o mas modelos de arquitectura. Cada
modelo debe contener identicaci on de version como los especica el proyecto
y/o organizacion. Cada modelo debe identicar el tipo de modelo que lo gobierna
y adherirse a las convenciones de ese tipo de modelo. Un modelo puede ser parte
de mas de una vista
Compartir: modelos de arquitectura entre vistas permite a una AD mostrar
diferentes pero relacionados intereses sin redundar o repetir la misma informa-
cion en m ultiples vistas y reducir las posibilidades de inconsistencias. COm-
partiendo modelos de arquitectura tambien permitimos un estilo orientado a
aspectos de AD.
Modelos de arquitectura compartidas a traves de las vistas pueden ser usado
para representar perspectivas/texturas de arquitectura Modelos de arquitectura
usarse como contenedorespara aplicar patrones de arquitectura o estilos para
expresar esquemas de arquitectura o estilos para expresar esquemas fundamen-
tales (capas, niveles p2p,) en las vistas
A.2.6. Reglas de relaciones
Una AD debe incluir cada regla de correspondencia que aplique a esta. Una
regla de correspondencia puede ser originada en la AD, Framework, punto de
vista o ADL. En caso de una regla de correspondencia identicada violada se
debe registrar, es decir, se deben registrar todas y cada una de las violaciones o
todas y cada una de las reglas de AD identicadas EN la norma las relaciones
son compatibles con las vistas de relacion de las normas ISO/IEC 10746 y 19793
A.2.7. Justicacion de la arquitectura
Registro de la Justicacion
Una AD debe tener una Justicacion para cada punto de vista en terminos
de Stakeholders, intereses, tipos de modelos, notacion y metodos. Una AD debe
tener una Justicacion para cada decision de una arquitectura clave. Una AD
debe tener evidencia de consideracion alternativas para las decisiones tomadas
A.2.8. Relacion de arquitectura
Consistencia en una AD
Una AD debe registrar toda inconsistencia conocida entre los modelos de
arquitectura y sus vistas iestras una AD consistente es preferida, esta muchas
veces es inviable o impractica para resolver todas las inconsistencias por razones
de tiempo, esfuerzo o informacion insucientes. Estas situaciones las inconsis-
tencias conocidas son registradas.
Una Ad podria incluir un analisis de consistencia de los modelos y sus vistas
Relaciones y reglas de correspondencia pueden ser usadas para expresar, regis-
54 AP
ON DE LA ARQUITECTURA 55
A.2.9. Registro de decisiones
Una AD debe llevar un registro de las decisiones claves tomadas. No es
practico registrar todas la decisiones tomadas. Se deben establecer criterios para
registrar decision claves. Criterios a considerar son:
Decisiones sobre requerimientos arquitectonicamente importantes
Decisiones que necesiten una mayor inversion de tiempo para ejecutarse,
implementarse o hacer cumplir
Decisiones que afecten Stakeholder claves o un n umero de estos
decision que son altamente sensitivas a cambios
decision que pueden costar para ser cambiadas
decision que son base para la planeacion de proyecto y administracion de
proyecto. Ejemplo:
Estructura de descomposicion de trabajo
Seguimiento de calidad
decision que resultan en gasto de capital o costos indirectos
Un AF debe establecer consistencia con el modelo conceptual. El requeri-
miento puede ser conocido a traves de un metamodelo, un mapeo de un AF
construyendo el modelo, una narrativa de texto o de alguna otra manera.
A.2.10. Adherencia de una AD y un AF
Una AD se adhiere a un AF cuando:
Cada Stakeholder que aplique, identicado en el AF ha sido considerado
e identicado en el AD
Cada interes aplicable, identicado en el AF ha sifo considerado en la AD
Cada punto de vista especicado por el AF es incluido en la AD
Cada regla de correspondencia especicada por el AF es incluida en la AD
la AD cumple con los requerimientos de especicados en esta norma
Un AF puede aplicar reglas adicionales para la adherencia
Una AD puede estar adherida a mas de un AF, pero tiene que haber
reconciliacion entre cada AF respecto a los elementos de AD
56 AP