IEEE 1471

IEEE 1471 es el nombre corto para un estándar formalmente conocido como ANSI / IEEE 1471-2000, Práctica recomendada para la descripción de arquitectura de sistemas intensivos en software. Dentro del lenguaje del Instituto de Ingenieros Eléctricos y Electrónicos (IEEE), esta es una "práctica recomendada", la menos normativa de sus normas. En 2007, esta norma fue adoptada por ISO / IEC JTC1 / SC7 como ISO / IEC 42010: 2007, Ingeniería de sistemas y software: práctica recomendada para la descripción arquitectónica de sistemas intensivos en software .[1]

Ha sido reconocido por mucho tiempo   que la "arquitectura" tiene una fuerte influencia sobre el ciclo de vida de un sistema. Sin embargo, hasta hace relativamente poco, ^[¿cuándo?] problemas de hardware han tendido a dominar el pensamiento arquitectónico, y los aspectos de software, cuando se consideraron, fueron a menudo los primeros en verse afectados por las presiones del desarrollo.[2] IEEE 1471 fue creado para proporcionar una base para pensar sobre la arquitectura de los sistemas intensivos en software.

Las contribuciones de IEEE 1471 se pueden resumir de la siguiente manera (en esta lista, los elementos en cursiva son términos definidos y utilizados en la norma):

• Proporciona definiciones y un meta-modelo para la descripción de arquitectura
• Declara que una arquitectura tendría que dirigir un sistema stakeholders preocupaciones
• Afirma que descripciones de arquitectura son inherently multi-vista, ninguna vista sola adecuadamente captura todo stakeholder preocupaciones
• Especifica las ideas de vista y punto de vista, donde un punto de vista identifica el conjunto de preocupaciones y las técnicas/de @modeling de las representaciones, etc. utilizados para describir la arquitectura para dirigir aquellas preocupaciones y una vista es el resultado de aplicar un punto de vista a un sistema particular.
• Establece requisitos de contenido para descripciones de arquitectura y la idea que una arquitectura de conformar la descripción tiene un 1-a-1 correspondencia entre sus puntos de vista y sus vistas.
• Proporciona guiaje para capturar arquitectura rationale e identificando incongruencias/asuntos irresolutos entre las vistas dentro de una descripción de arquitectura

IEEE 1471 proporciona anexos informativos que relacionan sus conceptos con conceptos de arquitectura en otros estándares, incluidos RM-ODP e IEEE 12207 .

En agosto de 1995, el Comité de Estándares de Ingeniería de Software de IEEE (SESC) organizó un Grupo de Planificación de Arquitectura de IEEE (APG) para establecer la dirección para incorporar el pensamiento arquitectónico en los estándares de IEEE. En abril de 1996, se creó el Grupo de Trabajo de Arquitectura (AWG) para implementar las recomendaciones hechas por APG al SESC. El AWG fue presidido por Basil Sherlund, los vicepresidentes Ronald Wade, David Emery, y la especificación fue editada por Rich Hilliard. El GTE tenía 25 miembros. Los borradores de la especificación fueron votados y comentados por 130 revisores internacionales. En septiembre de 2000, la Junta de Normas de IEEE-SA aprobó la especificación como IEEE Std 1471-2000.

En 2006, el Comité Técnico Conjunto ISO / IEC 1 (JTC1), Tecnología de la información / Subcomité SC 7, Ingeniería de software y sistemas, adoptó la especificación como ISO / IEC 42010, bajo un "procedimiento rápido" especial, en paralelo con su aprobación por organismos nacionales de ISO e IEC. Una revisión coordinada de este estándar por ISO / IEC JTC1 / SC7 / WG42 e IEEE CS comenzó en 2006, luego de la votación rápida de ISO / IEC y en línea con la revisión de 5 años del estándar IEEE.

En noviembre de 2011,[3] IEEE 1471-2000 e ISO / IEC 42010: 2007 fue reemplazado por ISO / IEC / IEEE 42010: 2011, Ingeniería de sistemas y software - Descripción de la arquitectura .

De acuerdo con IEEE 1471 [4][5][6] se puede utilizar una descripción de la arquitectura para lo siguiente:

• Expresión del sistema y su evolución.
• Comunicación entre los interesados del sistema.
• Evaluación y comparación de arquitecturas de manera consistente.
• Planificar, gestionar y ejecutar las actividades de desarrollo del sistema.
• Expresión de las características persistentes y principios de apoyo de un sistema para guiar el cambio aceptable.
• Verificación del cumplimiento de la implementación de un sistema con una descripción arquitectónica
• Registro de contribuciones al conjunto de conocimientos de arquitectura de sistemas intensivos en software

Según el Glosario estándar de IEEE de terminología de ingeniería de software [7] se utilizan las siguientes definiciones:

• Arquitecto : la persona, equipo u organización responsable del diseño de la arquitectura de sistemas.
• Descripción arquitectónica (AD): una colección de productos para documentar una arquitectura.
• arquitectura : la organización fundamental de un sistema incorporado en sus componentes, sus relaciones entre sí y con el medio ambiente, y los principios que guían su diseño y evolución.
• diseño : Las actividades de definir, documentar, mantener, mejorar y certificar la implementación adecuada de una arquitectura.
• sistema : una colección de componentes organizados para cumplir una función específica o un conjunto de funciones. El término sistema abarca aplicaciones individuales, sistemas en el sentido tradicional, subsistemas, sistemas de sistemas, líneas de productos, familias de productos, empresas enteras y otras agregaciones de interés.
• parte interesada del sistema : un individuo, equipo u organización (o clases de los mismos) con intereses o inquietudes en relación con un sistema.
• vista : Una representación de un sistema completo desde la perspectiva de un conjunto de preocupaciones relacionadas.
• punto de vista : una especificación de las convenciones para construir y usar una vista. Un patrón o plantilla a partir del cual desarrollar puntos de vista individuales estableciendo los propósitos y la audiencia para un punto de vista y las técnicas para su creación y análisis.

IEEE 1471 utiliza el siguiente marco conceptual.[8][9][10]

1. El entorno o contexto de un sistema puede influir en ese sistema. El entorno puede incluir otros sistemas que interactúan con el sistema de interés, ya sea directamente a través de interfaces o indirectamente de otras maneras. El entorno determina los límites que definen el alcance del sistema de interés en relación con otros sistemas.
2. Un sistema tiene una o más partes interesadas . Cada parte interesada generalmente tiene intereses o inquietudes en relación con ese sistema.
3. Las inquietudes son aquellos intereses relacionados con el desarrollo del sistema, su funcionamiento o cualquier otro aspecto que sea crítico o importante para una o más partes interesadas. Las preocupaciones incluyen consideraciones del sistema tales como rendimiento, confiabilidad, seguridad, distribución y capacidad de evolución.
4. Existe un sistema para cumplir una o más misiones en su entorno. Una misión es un uso u operación para la cual un sistema está destinado por una o más partes interesadas para cumplir algún conjunto de objetivos .
5. Cada sistema tiene una arquitectura, ya sea entendida o no; ya sea grabada o conceptual. Una arquitectura puede ser registrada por una descripción arquitectónica .
6. Una descripción arquitectónica se organiza en uno o más componentes llamados vistas (arquitectónicas). Cada vista aborda una o más de las preocupaciones de los interesados del sistema. Una vista es una expresión parcial de la arquitectura de un sistema con respecto a un punto de vista particular.
7. Un punto de vista establece las convenciones por las cuales se crea, representa y analiza una vista. De esta manera, una vista se ajusta a un punto de vista. El punto de vista determina los idiomas (incluidas las anotaciones, el modelo o los tipos de productos) que se utilizarán para describir la vista, y los métodos de modelado o técnicas de análisis asociados que se aplicarán a estas representaciones de la vista. Estos lenguajes y técnicas se utilizan para obtener resultados relevantes para las preocupaciones abordadas por el punto de vista.
8. Una descripción arquitectónica selecciona uno o más puntos de vista para su uso. La selección de puntos de vista generalmente se basa en la consideración de las partes interesadas a las que se dirige el AD y sus preocupaciones. Una definición de punto de vista puede originarse con un AD, o puede haberse definido en otro lugar (un punto de vista de la biblioteca ).
9. Una vista puede consistir en uno o más modelos arquitectónicos . Cada modelo arquitectónico se desarrolla utilizando los métodos establecidos por su punto de vista arquitectónico asociado. Un modelo arquitectónico puede participar en más de una vista.

IEEE 1471 [11] define un conjunto de requisitos normativos para las descripciones de arquitectura conforme, que incluyen lo siguiente:

• Identificación de AD, versión e información general (cláusula 5.1)
• Identificación de los interesados del sistema y sus preocupaciones consideradas relevantes para la arquitectura (cláusula 5.2)
• Especificaciones de cada punto de vista que se ha seleccionado para organizar la representación de la arquitectura y la justificación de esas selecciones (cláusula 5.3)
• Una o más vistas arquitectónicas (cláusula 5.4)
• Un registro de todas las inconsistencias conocidas entre los componentes requeridos de la descripción arquitectónica (cláusula 5.5)
• Una justificación para la selección de la arquitectura (cláusula 5.6)

• Vistas de arquitectura de software
• Marco de arquitectura empresarial
• Ver modelo

• Sitio web de IEEE 1471
• MEGAF es una infraestructura para realizar marcos de arquitectura que se ajustan a la definición de marco de arquitectura proporcionada en el estándar ISO / IEC 42010.