ISO/IEEE 42010:2011

Comienza Ya. Es Gratis
ó regístrate con tu dirección de correo electrónico
Rocket clouds
ISO/IEEE 42010:2011 por Mind Map: ISO/IEEE 42010:2011

1. Introducción

1.1. Establece requisitos para describir la arquitectura de sistemas y software

1.1.1. Mediante una convención, terminología común y mejores prácticas de Diseño y Descripción de Arquitectura.

1.1.2. Definición de arquitectura

1.1.2.1. Conceptos fundamentales o propiedades de un sistema en su entorno, materializados en sus elementos, relaciones y en los principios de su diseño y evolución”.

1.1.2.2. Producto de trabajo que muestra la arquitectura de un sistema conforme a la perspectiva de un conjunto de asuntos y aspectos del sistema

1.1.3. Evaluación

1.1.3.1. Son criterios para la evaluación de conformidad de una Arquitectura, extendiendo su utilidad en el ciclo de vida del sistema.

1.1.4. Creación

1.1.4.1. Fue desarrollada por el Comité Técnico paritario de Tecnologías de Información JTC1. Subcomité 7 Ingeniería de software y sistemas de ISO, la Comisión Electrotécnica Internacional en conjunto con el Instituto de Ingeniería Eléctrica y Electrónica

1.1.4.1.1. Sustituyendo al estándar IEEE Std 1471.

1.1.5. Clasificación

1.1.5.1. La norma ISO/IEC/IEEE 42010:2011 se clasifica en el campo de actividad 35 Tecnologías de información, grupo 35.080 Software.

2. Descripción de arquitectura, intereses y stakeholders

2.1. Se enfoca en la descripción de arquitectura como una expresión de la arquitectura, sin imponer o especificar un método, modelo o técnica particular de descripción de arquitectura

2.2. El sistema de interés es entendido como aquel que “configura hardware, software, datos, humanos, procesos, infraestructura, materiales y entidades”

2.3. La descripción de arquitectura debe identificar el sistema de interés y ser especificado según las necesidades del proyecto y objetivo, incluyendo información suplementaria de ser requerido

2.4. Se deben identificar los stakeholders (partes interesadas) con intereses fundamentales para la arquitectura, los cuales pueden ser: usuarios, operadores, compradores, propietarios, proveedores, desarrolladores, ensambladores, personal de mantenimiento, entre otros.

2.4.1. Por lo tanto, en un sistema de interés para uno o varios stakeholders, se identifican los intereses (concerns) desde un viewpoint (punto de vista) de arquitectura (numeral 4.2.3).

3. Desiciones, razonamientos, elementos y correspondencias de arquitectura

3.1. Las descripciones de arquitectura se basan en decisiones de arquitectura tomadas a partir de razonamientos de arquitectura (Architecture rationale)

3.1.1. Sobre las causas, consecuencias, alternativas e información fuente para la decisión de arquitectura (numeral 4.2.7).

3.2. Tanto las decisiones y razonamientos de arquitectura como las clases de modelo, modelos de arquitectura, vistas, puntos de vista, intereses y partes interesadas contienen elementos, afectados por las decisiones de arquitectura

3.2.1. Relacionadas entre sí a través de correspondencias que representan relaciones dentro de una misma descripción de arquitectura o entre descripciones de arquitectura.

3.3. En una descripción de arquitectura se deben identificar las correspondencias y los elementos que hacen parte (numeral 5.7.2)

3.3.1. identificando las reglas que la rigen, reglas que deben ser registradas incluyendo las violaciones.

4. Puntos de vista, vistas y modelos de arquitectura

4.1. Una descripción de arquitectura se realiza desde puntos de vista que permiten la expresión de un sistema según intereses de una o varias partes interesadas.

4.2. La descripción de arquitectura debe incluir cada punto de vista de arquitectura según lo dispuesto en esta norma y cada interés debe enmarcarse en por lo menos un punto de vista (numeral 5.4).

4.3. A su vez, una vista se compone de uno o varios modelos de arquitectura, regidos por las convenciones de la clase de modelo (model kind) que pueden ser diagramas, balances, organigramas, entre otros.

4.4. Un punto de vista debe especificar uno o más intereses y stakeholders relacionados, el tipo de modelo utilizado, los lenguajes, notaciones, convenciones y otros operadores aplicados y referencias a las fuentes empleadas.

4.4.1. deben especificar las técnicas de arquitectura aplicadas y pueden ser definidos desde un framework