Muchas veces me encuentro con la dificultad de explicar a que me dedico, o que es lo que hace el area en el que trabajo, o el rol que ocupo.
Voy a intentar explicar, de forma detallada, lo que endiendo por Arquitectura de Sistemas.
Primero, voy a mostrar algunas definiciones que encontre, y me fueron guiando en mi idea:
Según el IEEE, en el standard 1471-2000, la define como "la organización fundamental de un sistema, definida por sus componentes, las relaciones entre estos y entre los mismos y el ambiente que rodea al sistema, y los principios que gobiernan su diseño y evolución".
Por otro lado, según el SEI, son "construcciones intelectuales con importancia y duración grande, que gobiernan la forma en que se implementan los sistemas".
Uniendo un poco estas dos definiciones, y teniendo en cuenta también lo que dice bredemeyer acerca de este tema, yo definiría a la arquitectura de sistemas como:
La serie de decisiones que toma una persona o grupo de personas (los arquitectos), significativas para definir la organización de los sistemas, su implementación, gobierno y evolución.
Para tomar estas decisiones, se dividen los sistemas en componentes, sus relaciones entre estas, y se definen estos componentes y sus relaciones según reglas o buenas prácticas conocidas, de manera tal que el sistema en completo o parte del mismo cumpla con los requerimientos planteados por el mismo (funcionales, y principalmente los no funcionales, o atributos de calidad). Estas reglas o buenas prácticas pueden estar aplicadas a un componente en particular, a las relaciones entre estos, o a todos, tomando decisiones cross al sistema como un todo.
Estas decisiones no pueden tomarse a la ligera, se tienen que tener en cuenta distintos aspectos del sistema, y como una decisión puede impactar negativa o positivamente en un requerimiento en particular, pero puede impactar de manera muy distinta en otro. Es muy importante tambien, tener en cuenta que estas decisiones son tomadas durante todo el ciclo de vida del sistema, no solo al principio, y generalmente son dificiles de cambiar, por lo que en algunos documentos se las llama "decisiones duras".
Es un diseño de alto nivel, por lo que no debe confundirse con el diseño detallado de un sistema, pero las decisiones tomadas guian al diseño en si.
No solo se toman decisiones que impactan técnicamente en un sistema, sino que también se toman decisiones que tienen en cuenta la división de componentes para facilitar el desarrollo, el testing, la implementación, o la modificación de los mismos, o sea, mas relacionado con la gestión o trabajo sobre los componentes.
Lo dicho anteriormente resumen lo que, para mi, es la arquitectura de software.
Voy a intentar explicar, de forma detallada, lo que endiendo por Arquitectura de Sistemas.
Primero, voy a mostrar algunas definiciones que encontre, y me fueron guiando en mi idea:
Según el IEEE, en el standard 1471-2000, la define como "la organización fundamental de un sistema, definida por sus componentes, las relaciones entre estos y entre los mismos y el ambiente que rodea al sistema, y los principios que gobiernan su diseño y evolución".
Por otro lado, según el SEI, son "construcciones intelectuales con importancia y duración grande, que gobiernan la forma en que se implementan los sistemas".
Uniendo un poco estas dos definiciones, y teniendo en cuenta también lo que dice bredemeyer acerca de este tema, yo definiría a la arquitectura de sistemas como:
La serie de decisiones que toma una persona o grupo de personas (los arquitectos), significativas para definir la organización de los sistemas, su implementación, gobierno y evolución.
Para tomar estas decisiones, se dividen los sistemas en componentes, sus relaciones entre estas, y se definen estos componentes y sus relaciones según reglas o buenas prácticas conocidas, de manera tal que el sistema en completo o parte del mismo cumpla con los requerimientos planteados por el mismo (funcionales, y principalmente los no funcionales, o atributos de calidad). Estas reglas o buenas prácticas pueden estar aplicadas a un componente en particular, a las relaciones entre estos, o a todos, tomando decisiones cross al sistema como un todo.
Estas decisiones no pueden tomarse a la ligera, se tienen que tener en cuenta distintos aspectos del sistema, y como una decisión puede impactar negativa o positivamente en un requerimiento en particular, pero puede impactar de manera muy distinta en otro. Es muy importante tambien, tener en cuenta que estas decisiones son tomadas durante todo el ciclo de vida del sistema, no solo al principio, y generalmente son dificiles de cambiar, por lo que en algunos documentos se las llama "decisiones duras".
Es un diseño de alto nivel, por lo que no debe confundirse con el diseño detallado de un sistema, pero las decisiones tomadas guian al diseño en si.
No solo se toman decisiones que impactan técnicamente en un sistema, sino que también se toman decisiones que tienen en cuenta la división de componentes para facilitar el desarrollo, el testing, la implementación, o la modificación de los mismos, o sea, mas relacionado con la gestión o trabajo sobre los componentes.
Lo dicho anteriormente resumen lo que, para mi, es la arquitectura de software.
0 comentarios:
Publicar un comentario