ГОСТ Р 57100-2025. Национальный стандарт Российской Федерации. Системная и программная инженерия. Описание архитектуры

(утв. и введен в действие Приказом Росстандарта от 25.03.2025 № 215-ст)

ИСТОРИЯ ИЗМЕНЕНИЙ НОРМАТИВНО-ТЕХНИЧЕСКИХ АКТОВ

flowchart LR
  n0["ГОСТ Р 57100-2016"]:::rst
  click n0 "https://bukva.ai/docs/ost-54-3-175-72-99" "ГОСТ Р 57100-2016. Национальный стандарт Российской Федерации. Системная и программная инженерия. Описание архитектуры (утв. и введен в действие Приказом Росстандарта от 22.09.2016"
  n1["ГОСТ Р 57100-2025"]:::doc
  click n1 "https://bukva.ai/docs/standart-gost-r-57100-2025" "ГОСТ Р 57100-2025. Национальный стандарт Российской Федерации. Системная и программная инженерия. Описание архитектуры (утв. и введен в действие Приказом Росстандарта от 25.03.2025"
  n0 --> n1
classDef rst fill:#FFEBEB,stroke:#8B0000,color:#000;
classDef doc fill:#EBFFEB,stroke:#006400,color:#000;
classDef notEnt fill:#FFFFEB,stroke:#FF8C00,color:#000;

30 июня 2025 года

Предисловие

1 РАЗРАБОТАН Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО ИАВЦ) и Комиссией Российской академии наук по техногенной безопасности

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 022 «Информационные технологии»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 25 марта 2025 г. № 215-ст

4 Настоящий стандарт разработан с учетом основных нормативных положений международного стандарта ISO/IEC/IEEE 42010:2022 «Программные средства, системы и предприятия. Описание архитектуры» (ISO/IEC/IEEE 42010:2022 «Software, systems and enterprise — Architecture description», NEQ)

5 ВЗАМЕН ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

Введение

Сложность современных систем приводит к возникновению проблем для организаций, которые создают и используют эти системы. Чтобы помочь пониманию и управлению сложными системами, с которыми столкнулись заинтересованные стороны, все чаще применяются понятия, принципы и процедуры описания соответствующих архитектур. Настоящий стандарт расширяет комплекс национальных стандартов системной и программной инженерии в части описания архитектуры систем и их составных компонентов. Осмысление архитектуры системы, выражаемой в описании архитектуры, способствует пониманию системной логики и основных свойств, имеющих отношение к поведению, составу и развитию системы.

Основная цель стандарта заключается в помощи организациям, участвующим в создании (модернизации, развитии) и эксплуатации систем, в выражении архитектуры системы с помощью ее описания для формирования желаемых свойств, обеспечения выполнения системных требований и удовлетворения потребностей заинтересованных сторон. Структуры архитектуры и языки описания архитектуры создаются как активы, которые позволяют систематизировать соглашения и общие методы определения и описания архитектур в пределах различных сообществ и областей применения. Описания архитектур в своей практике используют заказчики, разработчики, поставщики, приобретающие и эксплуатирующие стороны, пользователи для улучшения взаимопонимания, связи и сотрудничества в жизненном цикле различных систем и их составных компонентов, а также для возможного влияния на функционирование, безопасность, качество, эффективность, сопровождаемость системы.

Настоящий стандарт обращается к созданию, анализу и выражению архитектур систем с помощью описаний архитектуры. В настоящем стандарте также определены условия для реализации желаемых свойств структур архитектуры и языков описания архитектуры в порядке целесообразной поддержки разработки и применения описаний архитектуры.

Положения настоящего стандарта могут быть использованы для систематизации практических действий при разработке описаний архитектуры системы с учетом контекста ее жизненного цикла и реализуемых процессов.

1 Область применения

Настоящий стандарт определяет способ, с помощью которого осуществляется выражение описания архитектуры систем, включая основные понятия, точки зрения на архитектуру, структуры и языки описания архитектуры. В настоящем стандарте демонстрируется его использование во взаимодействии с другими стандартами для процесса определения архитектуры системы.

В приложении А проиллюстрирована связь с другими стандартами, в приложении Б приведены примеры целей применения описания архитектуры, а в приложении В даны дополнительные пояснения по взаимосвязи жизненного цикла архитектуры системы с жизненным циклом соответствующего описания архитектуры.

Требования и рекомендации стандарта предназначены для использования организациями, участвующими в создании (модернизации, развитии) и эксплуатации систем и реализующими процесс определения архитектуры системы (см. [1] - [15]).

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

ГОСТ Р 51904 Программное обеспечение встроенных систем. Общие требования к разработке и документированию

ГОСТ Р 57102/ISO/IEC TR 24748-2:2011 Информационные технологии. Системная и программная инженерия. Управление жизненным циклом. Часть 2. Руководство по применению ИСО/МЭК 15288

ГОСТ Р 57193-2025 Системная и программная инженерия. Процессы жизненного цикла систем

ГОСТ Р 57839 Производственные услуги. Системы безопасности технические. Задание на проектирование. Общие требования

ГОСТ Р 58412 Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения

ГОСТ Р 58609 Системная и программная инженерия. Состав и содержание информационных элементов жизненного цикла (документации)

ГОСТ Р 59347 Системная инженерия. Защита информации в процессе определения архитектуры системы

ГОСТ Р 59991 Системная инженерия. Системный анализ процесса управления рисками для системы

ГОСТ Р 59994 Системная инженерия. Системный анализ процесса гарантии качества для системы

ГОСТ Р ИСО/МЭК 10746-1 Информационная технология. Открытая распределенная обработка. Базовая модель. Часть 1. Основные положения

ГОСТ Р ИСО/МЭК 10746-3 Информационная технология. Взаимосвязь открытых систем. Управление данными и открытая распределенная обработка. Часть 3. Архитектура

ГОСТ Р ИСО/МЭК 12207 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств

ГОСТ Р ИСО 14258 Промышленные автоматизированные системы. Концепции и правила для моделей предприятия

ГОСТ Р ИСО/МЭК 15414 Информационные технологии. Открытая распределенная обработка. Эталонная модель. Язык описания предприятия

ГОСТ Р ИСО 15704-2022 Моделирование и архитектура предприятия. Требования к стандартным архитектурам и методологиям предприятия

ГОСТ Р ИСО/МЭК 20000-1 Информационные технологии. Менеджмент сервисов. Часть 1. Требования к системе менеджмента сервисов

Примечание - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.

3 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1 архитектура (системы): Основные понятия или существенные свойства системы в окружающей среде и связанных процессах жизненного цикла системы, воплощенные в ее элементах, отношениях и конкретных принципах ее разработки, эксплуатации, сопровождения, модернизации и развития.

3.2 архитектурное представление: Информационный продукт, выражающий архитектуру некоторой системы с точки зрения определенных системных интересов.

3.3 вид модели: Категория модели, характеризуемая своими основными особенностями, условиями и соглашениями о моделировании.

Примечание - Примерами являются функциональные модели, аналитические модели функционирования системы, структурные модели, модели вариантов использования, экономические, геополитические модели.

3.4

3.5 интерес (системы или заинтересованной стороны): Польза или проблемы в системе, относящиеся к одной или нескольким заинтересованным сторонам.

Примечание - Интерес относится к любому воздействию на систему в ее окружающей среде, включая воздействия разработки, технологические, деловые, эксплуатационные, организационные, политические, экономические, юридические, регулирующие, экологические и социальные воздействия.

3.6 объект интереса: Предмет описания архитектуры.

Примечания

1 Примером объекта интереса могут служить предприятие, решение, система в целом, системный элемент, программные средства, подсистема, процесс, деятельность, данные (как элемент данных или структура данных), технология, стратегия, продукт, услуга, элемент программного или аппаратного обеспечения, линейка продуктов, семейство систем, система систем, совокупность систем, совокупность приложений.

2 «Объект интереса» относится к сущности, архитектура которой рассматривается при подготовке описания архитектуры.

3 В настоящем стандарте делается различие между объектом интереса и другими сущностями, которые не являются предметом описания архитектуры.

4 В настоящем стандарте интерес к какой-либо сущности подразумевает интерес к окружающей ее среде, жизненному циклу, архитектуре, требованиям, проектированию, реализации и эксплуатации. Такие интересы отражаются в виде аспектов, проблем, взглядов или позиций заинтересованных сторон.

3.7 окружающая среда: Контекст или условия, определяющие параметры и обстоятельства всех воздействий на систему.

Примечание - Окружающая среда системы включает воздействия разработки, технологические, деловые, эксплуатационные, организационные, политические, экономические, юридические, регулирующие, экологические и социальные воздействия.

3.8 описание архитектуры: Информационный продукт, используемый для выражения архитектуры.

3.9 основы архитектуры: Соглашения, принципы и практические методы описания архитектуры, установленные в конкретной области применения или объединении заинтересованных сторон.

Примечания

1 Основой архитектуры могут выступать, например, обобщенная стандартная архитектура предприятия и методологии по ГОСТ Р ИСО 15704.

2 Также некоторой основой архитектуры может служить эталонная модель открытой распределенной обработки по ГОСТ Р ИСО/МЭК 10746-1, ГОСТ Р ИСО/МЭК 10746-3.

3.10 процесс определения архитектуры (системы): Процесс формирования замысла и концептуальных основ, выражения, документирования, взаимодействия, соответствующего подтверждения соответствия при реализации, сопровождения и совершенствования архитектуры в жизненном цикле системы.

3.11 структура описания архитектуры: Соглашения, принципы и практические методы описания архитектур, установленные в конкретной области применения или сообществе заинтересованных сторон.

Примечание — Примером могут служить стандартизованные архитектура предприятия с описанием (см. ГОСТ Р ИСО 15704), модель открытой распределенной обработки (см. ГОСТ Р ИСО/МЭК 10746-3).

3.12 точка зрения на архитектуру: Набор соглашений по созданию, интерпретации и использованию архитектурного представления для определения системных интересов.

3.13 элемент описания архитектуры; элемент ОА: Идентифицированная или поименованная часть описания архитектуры.

Примечание - К элементам описания архитектуры относятся заинтересованные стороны, интересы, взгляды и позиции заинтересованных сторон, учитываемые аспекты, определенные в описании архитектуры, язык описания архитектуры, основные понятия описания архитектуры, соответствие и методы проверки соответствия, используемые в описании архитектуры, а также представления архитектуры, компоненты представления архитектуры, точки зрения на архитектуру и виды моделей, включенные в описания архитектуры.

3.14 язык описания архитектуры: Средство выражения, которое обладает синтаксисом и семантикой и состоит из набора репрезентаций, соглашений и связанных с ними правил, предназначенных для использования при описании архитектуры.

4 Соответствие

Существуют следующие пять ситуаций, когда можно заявлять о соответствии положениям настоящего стандарта:

• соответствие заявлено для описания архитектуры. В заявлении должно быть указано, что описание архитектуры соответствует требованиям и рекомендациям, указанным в разделе 6;
• соответствие заявлено для структуры описания архитектуры. В заявлении должно быть указано, что структура описания архитектуры соответствует требованиям и рекомендациям, указанным в 7.1;
• соответствие заявлено для языка описания архитектуры. В заявлении должно быть указано, что язык описания архитектуры соответствует требованиям и рекомендациям, указанным в 7.2;
• соответствие заявлено для точки зрения на архитектуру. В заявлении должно быть указано, что точка зрения на архитектуру соответствует требованиям и рекомендациям, указанным в 8.1;
• соответствие заявлено для вида модели. В заявлении должно быть указано, что спецификация вида модели соответствует требованиям и рекомендациям, указанным в 8.2.

Примечания

1 После заявления о соответствии для использования «приспосабливание» стандарта не требуется.

2 Возможно «приспосабливание» положений настоящего стандарта в части раздела 6, 7.1, 7.2, 8.1, 8.2 на основе применения положений о приспосабливании, приведенном в ГОСТ Р 57193-2025, пункт 4.3.

5 Концептуальные основы

5.1 Контекст описания архитектуры

Термин «система» использован в настоящем стандарте для обращения к конкретным сущностям, архитектура которых подлежит описанию. Так, термин охватывает (но не ограничивается этим) конкретные сущности:

• системы (см. ГОСТ Р 57193);
• программные системы и средства (см. ГОСТ Р ИСО/МЭК 12207, ГОСТ Р 51904, ГОСТ Р 58412);
• промышленные объекты (см. ГОСТ Р ИСО 14258, ГОСТ Р ИСО 15704);
• сервисы и услуги (см. ГОСТ Р ИСО/МЭК 20000-1, ГОСТ Р 57839).

Примечание - Стандарт не определяет, где находится или из чего состоит система в пределах тех или иных областей, а также не рассматривает конкретную природу систем.

Заинтересованные стороны формируют для системы различные цели. Цели являются одним из видов выражения интересов.

Система находится в окружающей среде, характеризуемой параметрами, условиями и обстоятельствами различных воздействий на систему, включая взаимодействия самой системы с окружающей средой. Окружающая среда какой-либо системы может содержать другие системы.

Архитектура какой-либо системы представляет собой основные понятия или существенные свойства системы в окружающей среде в условиях связанных процессов жизненного цикла системы, воплощенные в ее элементах, отношениях и конкретных принципах ее разработки, эксплуатации, сопровождения, модернизации и развития. Главное — ориентация на достижение целей системы. Вместе с тем, необходимо учитывать, что может не существовать единственной характеристики того, что является существенным или основным для системы. Существенными могут оказаться характеристики системных компонентов или элементов, алгоритмы того, как системные элементы устроены или взаимосвязаны, принципы организации системы, или проекта, или развития системы в ее жизненном цикле. Для системных ответов на возникающие вопросы, связанные с определением существенных угроз и условий, способных при том или ином развитии событий повлиять на свойства рассматриваемых системных процессов, системы (и/или ее элементов) и/или проекта, может быть использован риск-ориентированный подход на базе вероятностного моделирования (см. ГОСТ Р 59991).

ОА концептуально используется для выражения архитектуры рассматриваемой системы, как показано на рисунке 1.

Примечания

1 Та же самая система может оказаться более понятной с помощью несколько отличающихся архитектур (например, когда они рассматриваются в различных окружающих средах). Архитектура может быть выражена с помощью нескольких отличающихся описаний архитектуры (например, когда используются различные основы архитектуры). Та же самая архитектура может характеризовать более чем одну систему (например, семейство схем деления какой-то более общей архитектуры).

2 Объект интереса может быть выявлен в результате анализа интересов заинтересованных сторон и перспектив развития системы.

3 Объект интереса обычно выявляется в результате системного анализа множества возникающих проблем. Проблема может быть описана с помощью определения архитектуры набора функциональных возможностей (на практике называемой «архитектурой возможностей»). На этапе определения возможностей выявленные заинтересованные стороны потенциально заинтересованы в будущем объекте интереса.

5.2 Концептуальная модель основ описания архитектуры

Описания архитектуры — это информационные продукты, используемые для выражения архитектуры. На рисунке 2 изображены понятия, имеющие отношение к практике описания архитектуры, если настоящий стандарт применяется для создания одного описания архитектуры, выражающего одну архитектуру для одной рассматриваемой системы.

Термин «рассматриваемая система» (или просто «система») относится к системе, архитектура которой находится на рассмотрении в подготовке описания архитектуры.

Формирование концептуальной модели основ описания архитектуры отражено на рисунке 2.

Примечание - Положения стандарта охватывают лишь описание архитектуры (не саму архитектуру). В стандарте отсутствуют какие-либо требования, имеющие отношение к архитектуре или системам, или к их окружающей среде. Стандарт не предлагает конкретного процесса или метода для осуществления описания архитектуры, не предписывает определенных методов процесса определения архитектуры, моделей, нотаций или методик, используемых для осуществления описаний архитектуры.

5.3 Заинтересованные стороны, интересы, взгляды и позиции

У заинтересованных сторон системы существуют интересы относительно рассматриваемой системы в соответствующей окружающей среде. Интерес может проявляться одной или более заинтересованными сторонами. Интересы возникают в жизненном цикле из потребностей системы и требований, из выбора тех или иных решений при проектировании, из результатов системного анализа при реализации и эксплуатации. Интерес может быть заявлен в различных формах, например таких, как определение соответствия потребностям заинтересованной стороны, формулирование целей, ожиданий, взаимодействий, обязательств, формирование системных, и/или технических, и/или программных, и/или технологических, и/или методических, и/или организационных требований, установление ограничений проекта, предположений и допущений, зависимостей, предпочтения в архитектурных решениях, отношения к тем или иным угрозам, имеющим отношение к системе.

Примечание — Примерами интересов в терминах настоящего стандарта являются: функциональность, выполнимость, применимость, цели системы, характеристики системы, свойства системы, задаваемые ограничения, структура, поведение, функционирование, использование ресурсов, надежность, безопасность, информационное обеспечение, сложность, способность к развитию, открытость, параллелизм, автономность, стоимость, расписание, качество услуг, гибкость, динамичность, модифицируемость, модульность, управление, межпроцессные связи, взаимоблокировки, изменение состояния, интеграция подсистем, доступность данных, частная жизнь, соответствие требованиям регуляторов, гарантии, деловые цели и стратегии, опыт заказчика, сопровождаемость, приемлемость и утилизируемость. Прозрачность распределения, описанная в эталонной модели открытой распределенной обработки по ГОСТ Р ИСО/МЭК 10746-1, также может представлять собой интерес в терминах настоящего стандарта.

Заинтересованные стороны могут образовывать отдельные группы, характеризующиеся определенными взглядами и позициями, основанными на их общей роли, опыте, убеждениях или иных отношениях к системе. Взгляд может отражать знания в предметной области, профессиональный опыт, обучение или близость к объекту интереса в течение его жизненного цикла (например, к этапам проектирования, разработки, производства, поставки, эксплуатации и использования). Взгляды и позиции заинтересованных сторон — это способы осмысления объекта интереса в конкретном контексте.

Цель описания архитектуры заключается в выявлении интересов, выражаемых во взглядах заинтересованных сторон в определенном контексте.

Примечание - Примерами взглядов заинтересованных сторон могут служить взгляды на промышленную производственную систему применительно к операционной деятельности и финансам, взгляды на банковскую систему с точки зрения бизнеса или управления, взгляды на разработку, развертывание и настройку мобильного приложения, взгляды поставщиков и потребителей на оказываемые услуги.

5.4 Учитываемые аспекты и архитектурные принципы

Учитываемые аспекты отражают набор характеристик или особенностей объекта интереса в окружающей его среде для определения архитектуры, позволяющей учесть и обеспечить соответствие интересам заинтересованных сторон.

Использование известных аспектов, основанных на предыдущем опыте в той или иной области применения, позволяет на системной основе учитывать существующие интересы, а также выявлять новые. Учитываемые аспекты, основанные на опыте, являются более объективными по своей природе. С использованием системного анализа различных аспектов можно выявлять или предсказывать соответствующие характеристики или свойства объектов интереса. Анализ аспектов может выявить один или несколько новых интересов к системе. Определение взаимосвязей между аспектами и интересами основано на опыте архитекторов и оценивается заинтересованными сторонами с учетом их целей, понимания и знаний.

Архитектурные принципы охватывают существенные факторы, интересы, взгляды заинтересованных сторон и различные аспекты, которые необходимо и целесообразно учитывать при определении и описании архитектуры. К архитектурным принципам могут быть, например, отнесены: способность заинтересованных сторон интерпретировать выбранные языки описания архитектуры для выражения своих взглядов, необходимый уровень формализации точек зрения и видов моделей, наличие инструментариев поддержки, стандартные методы, применяемые в конкретной отрасли, наличие времени и ресурсов, важность глубины понимания, которую необходимо достичь заинтересованным сторонам.

Архитектурные принципы полезны при формулировании точки зрения на архитектуру, а также при создании, интерпретации, организации или использовании архитектурных представлений. Применение архитектурных принципов позволяет группировать различные точки зрения на архитектуру, например по отношению ко взглядам и позициям заинтересованных сторон.

5.5 Архитектурные представления и точки зрения на архитектуру

Описание архитектуры включает одно или несколько архитектурных представлений. Архитектурное представление обращается к одному или более интересам, имеющим место от заинтересованных сторон системы.

Архитектурное представление выражает архитектуру рассматриваемой системы в соответствии с точкой зрения на архитектуру. Точка зрения отражает интересы, которые преследуют заинтересованные стороны, и условности, которые устанавливаются в архитектурных представлениях.

Какая-либо точка зрения на архитектуру отражает один или более интересов. Интерес может быть описан более чем одной точкой зрения.

Архитектурное представление определяется точкой зрения на архитектуру: точка зрения устанавливает условности для конструирования, интерпретации и анализа представления для того, чтобы обратиться к интересам, представленным этой точкой зрения. Условности точки зрения могут включать языки, нотации, виды моделей, правила проектирования и/или методы моделирования, методики анализа и другие операции в представлениях. Спецификация точки зрения на архитектуру представляет собой соглашения (например, элементы ОА, синтаксис и семантику, рекомендации по использованию и направление) для тех, кто создает, интерпретирует или использует архитектурные представления.

На рисунке 3 отражены отношения между представлениями и точками зрения в описании архитектуры.

5.6 Архитектурные модели и компоненты архитектурного представления

Архитектурное представление формируется на базе одной или более архитектурных моделей. Архитектурная модель использует условности моделирования, соответствующие удовлетворению конкретных интересов. Эти условности определяются видом модели. В пределах описания архитектуры модель может быть частью более чем одного архитектурного представления.

Вид модели определяет характер действий и взаимодействий для компонентов представления, основанных на модели. Описание модели документирует соглашения для компонентов представления. Сюда относятся предполагаемое использование, терминология, обозначения, их синтаксис и семантика, а также символика для управляемых моделей. Вид модели и описание модели могут быть использованы более чем одной точкой зрения в описании архитектуры. Если содержание в своей основе относится к нескольким представлениям в рамках описания архитектуры, то чтобы обеспечить совместное использование информации, компонент архитектурного представления может входить в состав других представлений.

Примечания

1 Виды моделей включают варианты использования, модели действий (например, модели структурного анализа и проектирования), модели угроз, модели компонентов и их взаимосвязей.

2 Диаграмма потока данных может быть компонентом функционального представления. Отдельная диаграмма потока управления может быть вторым компонентом в том же функциональном представлении. Функциональное представление может также содержать описание, объясняющее методику интерпретации диаграммы потоков в этом представлении. Диаграммы потоков основаны на моделях, а их описания — нет. Диаграмма потока данных может быть частью представления в области обеспечения информационной безопасности.

3 Таблица символов может также отражать описание функционального представления.

На рисунке 4 отражен пример концептуальной модели представлений и их компонентов в описании архитектуры.

и их компонентов

Примечание — В настоящем стандарте используется термин «вид модели», а не «вид архитектурной модели», для того чтобы подчеркнуть, что виды модели могут быть полезными не только исключительно в описаниях архитектуры.

5.7 Элементы описания архитектуры

Элемент ОА — это одно или несколько архитектурных понятий в составе описания архитектуры. Примерами элементов ОА являются такие архитектурные понятия, как заинтересованная сторона, интерес, аспект, позиция заинтересованной стороны, точка зрения на архитектуру, архитектурное представление, вид и описание модели, компонент архитектурного представления, архитектурное решение, обоснование архитектуры, а также любое соответствие и методы соответствия, используемые в этих понятиях.

Элемент ОА внутри описания архитектуры может быть уточнен и детализирован с помощью ссылки на другое описание архитектуры. Описание архитектуры может использовать протоколы, представленные как элементы описания архитектуры в различных формах представления описания архитектуры.

По мере определения и применения точек зрения, видов и описаний моделей появляются дополнительные элементы ОА. Главная точка зрения, вид и описание модели определяют синтаксис и семантические соглашения для этих новых элементов ОА.

Примечание — Элементы ОА, представленные с помощью точек зрения или видов моделей, включают в себя конструктивы вариантов использования (например, предварительные условия, участники, ограничения системы), конструктивы моделей действий (сами действия, входные данные, выходные данные, средства и механизмы контроля), а также типовые схемы архитектуры или проектирования, которые будут применяться.

5.8 Методы представления

Спецификация точки зрения на архитектуру включает в себя один или несколько методов представления. Методы представления позволяют отображать инструкции, эвристические правила, показатели, схемы, правила проектирования или рекомендации по проектированию, передовые практики и примеры, помогающие в восприятии представлений и использовании других представлений. Методы представления устанавливают правила выражения, применяемые расчетные модели, технологии анализа и другие операции с представлениями. Эти методы определяют элементы ОА, используемые при создании представления, а также методы анализа, опроса или запроса представлений для оценки интересующих свойств. Требования и рекомендации по методам представления приведены в 8.3.

Методы представления подразделяются на следующие категории:

• методы построения — это способы, с помощью которых создаются представления с использованием точек зрения. Это могут быть руководящие указания по процессу (с чего начать, что делать дальше), руководящие указания по описанию (схемы для представлений такого типа) или эвристические методы, стили, шаблоны и другие идиомы для использования;
• методы интерпретации — это средства, которые обеспечивают понимание представления заинтересованными сторонами и другими пользователями;
• методы анализа — используются для контроля, проверки, осмысления, преобразования, прогнозирования, применения и оценки результатов, полученных для этого представления.

Методы представления обычно устанавливаются в рамках точки зрения, их используют или на них ссылаются виды моделей, рамочные структуры описания архитектуры и языки описания архитектуры.

Примечание — Примерами методов представления могут быть, например, методы, которые относятся к: цепочке зависимостей для оценки влияния изменений; анализу компромиссов в области качества или рассмотрения других вопросов; анализу ограничений для определения качества проработки контекста и объекта интереса; руководящим указаниям по схемам деления; анализу сложности архитектуры; созданию и применению стилей архитектуры (таких как многоуровневость, аспекто- или предметно-ориентированность); семействам схем для продвижения предполагаемых свойств объекта интереса; анализу требований к полноте и охвату в описании архитектуры; интерпретации и интеграции внешних моделей в качестве источников информации.

5.9 Связь элементов описания архитектуры

Связь элементов ОА определяет установленную или поименованную связь между двумя и более элементами ОА.

Выделяют следующие типы связи элементов ОА:

• одного или нескольких элементов ОА с элементами ОА в рамках описания архитектуры;
• одного или нескольких элементов ОА с элементами ОА, представленными в нескольких описаниях архитектуры;
• одного или нескольких элементов ОА с элементами ОА в рамках понятий одного описания архитектуры или нескольких описаний архитектуры;
• одного или нескольких элементов ОА с элементами ОА, которые используют один или несколько языков описания архитектуры.

Для целей установления связей описание архитектуры может рассматриваться как элемент ОА другого описания архитектуры.

Связи элементов ОА могут использоваться для указания на отношения внутри и между элементами описания архитектуры, для облегчения корреляции между описаниями архитектуры связанных систем или в целях скоординированности интерпретации и анализа связанных описаний архитектур.

Связи элементов ОА регулируются методом представления, который выражает правила, практические подходы или модели для определения конкретной связи между элементами ОА. Связи описания архитектуры и соответствующие методы используют для выражения и соблюдения таких отношений, как композиция, уточнение, согласованность, прослеживаемость, зависимость, ограничение, удовлетворенность заинтересованных сторон в отображении элементов ОА в архитектуре. Метод представления связи может отражать то, что все элементы ОА отвечают конкретному интересу или удовлетворяют конкретному требованию заинтересованной стороны. Связи по этому методу могут быть зафиксированы в виде матрицы прослеживаемости с обоснованием каждого элемента ОА, который нельзя проследить до интереса или требования.

Примерами связей элементов могут служить: связь между элементом ОА в рамках представления и интересом, которому эта связь отвечает; связь между архитектурным представлением и аспектом, в котором эта связь задействована; связь между элементом ОА и функцией, которую элемент ОА реализует; связь между интерфейсом компонента и набором стандартов, которым соответствует интерфейс; связь между объектом данных в потоке функций и полным определением структуры данных; связь между системой и организационной структурой, свойственной этой системе.

Примечание - Реализация связи элемента с самим собой — это действие, которое генерирует два (или более) действия такого же типа, или действие, которое рекурсивно вызывает само себя.

5.10 Архитектурные решения и их обоснования

Архитектурное решение — это набор выбранных вариантов решений в общем контексте архитектуры. Эти выбранные варианты обычно относятся к различным элементам ОА, требованиям сущности или влияниям окружающей среды на архитектуру. Примерами решений могут служить: архитектурная концепция или технический проект, элемент ОА, множество понятий описания архитектуры, схемы деления применительно к различным уровням архитектуры, базовая технология, бизнес-компонент, методы и средства обеспечения качества и/или безопасности системы, бизнес-процессы, алгоритмы использования описания архитектуры, диапазон применения технологий реализации описания архитектуры, комплекс показателей для системного анализа в проекте.

В обосновании архитектурного решения документируют объяснения, аргументацию, факты, рассуждения о причинах в принятых решениях. Обоснование решения обычно отражает следующие аспекты: основания для принятия решения, архитектурные принципы, методологические основы для выработки решения и проведения системного анализа (см. ГОСТ Р 59347, ГОСТ Р 59991, ГОСТ Р 59994), оценки влияния решений на показатели качества и/или безопасности, рассмотренные альтернативные варианты, возможные последствия принятого решения, а также ссылки на источники дополнительной информации.

Примерами обоснований решения могут также служить ссылки на соблюдение финансовых обязательств, выполнение обязательств по срокам, существующие ограничения в конкретных условиях эксплуатации, применение проверенных технологий, аргументы по минимизации доработок, сокращению капитальных вложений, достижению совместимости интерфейсов, выбору инструментариев моделирования для согласования с соответствующей архитектурой и обеспечения совместимости и прослеживаемости выполнения требований технического задания на разработку (модернизацию) системы.

Архитектурные решения относятся к системным интересам, однако между двумя интересами может не оказаться простых удовлетворительных решений. Решения могут воздействовать на архитектуру несколькими способами. Они могут быть отражены в описании архитектуры следующим образом:

• формулированием требований существенных элементов ОА;
• изменением свойств элементов ОА;
• подключением системного анализа компромиссов для некоторых элементов ОА, включая иные решения и интересы, в которых имеют (могут иметь) место изменения;
• порождением новых интересов.

5.11 Процесс определения архитектуры в жизненном цикле системы

Процесс определения архитектуры, включающий в себя создание и сопровождение описания архитектуры, имеет место в рамках контекста системы, проекта и/или организации и выполняется в пределах всего жизненного цикла системы (см. ГОСТ Р 57193). Процесс определения архитектуры способствует разработке, функционированию и сопровождению системы от стадии изначального замысла до выведения ее из эксплуатации. Поэтому архитектура системы потенциально влияет на другие процессы в пределах всего жизненного цикла системы. Вместе с тем, настоящий стандарт не зависит, не предполагает и не предписывает какого-либо особенного жизненного цикла для описания архитектуры.

В течение жизненного цикла объекта интереса описание архитектуры может предшествовать процессам создания, обновления или изменения архитектуры либо следовать за ними. Архитектура объектов интереса имеет свой жизненный цикл, само описание архитектуры и его составные компоненты также имеют свой собственный жизненный цикл. В ходе разработки архитектуры определяется ее необходимость, формулируются основные концепции, детализируются ее элементы, проводится анализ компромиссов и возможных вариантов реализации, которые затем оцениваются, утверждаются, готовятся к использованию и вводятся в эксплуатацию. Впоследствии описание архитектуры может быть обновлено и появятся его новые версии. В идеальном случае этапы эксплуатации являются длительными и стабильными, при этом использование общей архитектуры в жизненном цикле нескольких сущностей выступает, как правило, залогом приемлемой эффективности и устойчивости функционирования системы.

В то же время жизненный цикл любого объекта во многом определяется жизненным циклом его архитектуры. К примеру, решения о вложении средств в проект по разработке системы на основе существующих систем в рамках системы услуг во многом определяются наличием стабильной, надежной, общей и согласованной архитектуры относительно интегрирующей инфраструктуры.

При планировании жизненного цикла системы учитываются прогнозируемые этапы жизненного цикла выбранной архитектуры. Создание архитектуры включает в себя рассмотрение объекта интереса с различных сторон, при этом выявляемые точки зрения на архитектуру также должны учитываться на различных этапах жизненного цикла. Так, разработчик архитектуры будет рассматривать какую-либо сущность с позиции бизнеса, охватывая ее идентичность и концепцию (например, роль на рынке, возможности, взаимосвязь с контекстом бизнеса, а также политики и принципы, используемые для управления решением). Будет проведен анализ высокоуровневых требований (функциональных и нефункциональных), которым должна удовлетворять сущность, и эти требования будут выражены в спецификации с позиции бизнес-аналитика. Разработчик архитектуры преобразует эти требования спецификации в архитектурное решение, которое станет предварительным проектом объекта интереса и подготовит его для последующей оценки.

Примечание - Приложение А демонстрирует, как настоящий стандарт может быть использован в контексте таких стандартов, как ГОСТ Р ИСО 15704, ГОСТ Р ИСО/МЭК 12207, ГОСТ Р 57193, ГОСТ Р ИСО/МЭК 10746-3.

5.12 Структуры и языки описания архитектуры

Структуры и языки описания архитектуры определяются на основании понятий описания архитектуры, представленных в настоящем стандарте.

Структуры описания архитектуры, используемые при создании общего объекта интереса в рамках конкретной практической области, обычно определяют точки зрения на архитектуру для ожидаемых или известных архитектурных принципов в виде позиций заинтересованных сторон, интересов или аспектов, связанных со структурой, функциями и жизненным циклом.

Точка зрения на архитектуру в структуре описания архитектуры, которая служит руководством или дает ссылки на специализированные структуры описания архитектуры, определяет типовые интересы, аспекты, виды моделей и методы представления, позволяя приходить к соглашениям о главном представлении, связанном с конкретной точкой зрения. Кроме того, пользователи обобщенной структуры описания архитектуры могут с ее помощью определять архитектурные принципы и спецификации точек зрения на архитектуру и использовать полученные архитектурные представления при реализации архитектуры конкретного объекта интереса.

Структура описания архитектуры устанавливает практику для создания, интерпретации, анализа и применения описания архитектуры в пределах определенной области применения или сообщества заинтересованных сторон. Выбор структуры описания архитектуры в качестве эталонной позволяет использование общих архитектурных принципов и согласованной общей терминологии в предметной области интересов. Однако внедрение стандартных решений обычно требует необходимой адаптации и настройки с учетом конкретных условий и ожиданий заинтересованных сторон. Структура описания архитектуры призвана обеспечить достижение конкретной цели или эффективное понимание архитектуры заинтересованными сторонами, финансирующими работы по созданию системы. В результате внедрения специализированных элементов ОА может потребоваться изменение лексики и спецификаций точек зрения на архитектуру.

Специализированная структура описания архитектуры или предназначенная для внедрения, а не для использования в качестве эталонной структуры описания архитектуры, может охватывать конкретные и возможно более детализированные интересы заинтересованных сторон, специфические аспекты и зачастую лишь узкую часть жизненного цикла системы.

Использование структуры описания архитектуры в различных ситуациях позволяет выявлять новые комбинации архитектурных принципов и полезных точек зрения, видов моделей, описаний, обоснований, представлений и связей. В зависимости от ситуации возможны следующие варианты:

• исключение этапа жизненного цикла;
• учет только некоторых заинтересованных сторон или аспектов;
• учет перекрывающихся наборов аспектов;
• учет только подчиненных предметных областей или подгрупп аспектов;
• учет новых или адаптированных точек зрения по мере возникновения новых интересов;
• выявление ранее не реализованных связей.

Чтобы лучше понять свои интересы, заинтересованные стороны обычно рассматривают их с разных позиций и с учетом различных аспектов объекта интереса, таких как структура, функционирование системы и взаимосвязи элементов. Одни заинтересованные стороны могут рассматривать архитектуру с позиции бизнеса, и их интересует необходимая или предоставляемая функциональность (например, какие возможности объекта реализованы или модифицированы, какие новые процессы необходимы), а другие — могут рассматривать архитектуру с экономической точки зрения. Их могут интересовать больше финансовые результаты, обеспечиваемые этой функциональностью (например, каковы финансовые показатели от внедрения инвестиций, каково ожидаемое влияние на конечный результат).

Применение структур описания архитектуры включает (но не ограничивается этим): создание описаний архитектуры; разработку инструментариев моделирования архитектуры и методов процесса определения архитектуры; установление процессов для содействия связи, обязательствам и межсистемному функционированию через множественные проекты и/или несколько организаций.

Примечание — Структуры описания архитектуры часто охватывают условия и дополнительные практики в процессе определения архитектуры. Так, при переходе от общих моделей к эталонным (частичным) и специализированным моделям применяются одни и те же концепции, изложенные ранее (см. ГОСТ Р ИСО 15704).

Язык описания архитектуры является некоторой формой выражения для применения в описании архитектуры. Язык описания архитектуры обеспечивает один или несколько видов модели в качестве средства структуризации некоторых интересов для представителей заинтересованных сторон. Язык описания архитектуры может быть узко ориентированным, определяющим единственный вид модели, или широко ориентированным, предназначенным для обеспечения нескольких видов модели, специально организованных для представления точки зрения. Часто язык описания архитектуры поддерживается автоматизированными инструментариями для сопровождения создания, использования и анализа его моделей. Примерами могут служить языки описания архитектуры по эталонной модели открытой распределенной обработки (см. ГОСТ Р ИСО/МЭК 10746-3).

На рисунке 6 отображена концептуальная модель языка описания архитектуры.

Язык описания архитектуры обеспечивают необходимую строгость при разработке описания архитектуры. Семантика языка описания архитектуры может быть определена с разной степенью формализации и возможностей выражения с помощью словаря или глоссария на естественном языке, таксономии терминов и их отношений, метамодели, определяющей использование языковых конструкций, онтологической теории, использующей аксиомы в формальной логике для достижения целей в определении архитектуры системы (см. 7.3).

5.13 Применения описаний архитектуры

У описаний архитектуры существует много применений со стороны различных заинтересованных сторон по всему жизненному циклу системы. Описания архитектуры применяются (но не ограничиваются этим):

• в качестве основы системного проекта системы и действий по разработке;
• в качестве основы анализа и оценки альтернативных реализаций архитектуры;
• в качестве документации в разработке и сопровождении;
• для обеспечения документирования существенных аспектов системы, например таких, как: - намеченное использование и окружающая среда; - принципы, предположения и ограничения для проведения будущих изменений; - моменты для обеспечения гибкости или ограничений системы относительно будущих изменений; - решения архитектуры, их обоснования и последствия;
• в качестве источников исходных данных для автоматизированных инструментариев при моделировании, имитации и системном анализе;
• для определения системных групп, разделяющих общие свойства (такие, как архитектурные стили, эталонные архитектуры и архитектуры линейки продуктов);
• для обеспечения связи между сторонами, вовлеченными в разработку, производство, развертывание, функционирование и сопровождение системы;
• в качестве основы для подготовки документов приобретения (например таких, как запросы о предложении и описание требуемых работ);
• для обеспечения связи между заказчиками, приобретающими сторонами, поставщиками и разработчиками как части контрактных переговоров;
• для обеспечения документирования характеристик, свойств и проекта системы в интересах потенциальных заказчиков, приобретающих сторон, собственников, операторов и интеграторов;
• при планировании передачи документов по новой и устаревшей архитектурам;
• в качестве руководства к эксплуатационной и инфраструктурной поддержке и управлению конфигурацией;
• для поддержки системного планирования и действий, связанных со сроками и бюджетом;
• для установления критериев при сертификации соответствия архитектуры;
• в качестве механизма согласования с внешней и проектной политикой и/или внутренней политикой организации (например, юридические основания, перекрывающие архитектурные принципы);
• в качестве основы для ревизий, анализа и оценки системы в ее жизненном цикле;
• в качестве основы анализа и оценки альтернативных архитектур;
• при распространении изученных уроков и повторном использовании архитектурных знаний через точки зрения, образцы и стили;
• для обучения и образования заинтересованных сторон и других сторон лучшим методам в процессе определения архитектуры и при развитии системы.

Примечание — В приложении А рассмотрено использование описаний архитектуры в контексте других стандартов.

6 Спецификация описания архитектуры

6.1 Идентификация описания архитектуры и дополнительные сведения

В описании архитектуры должны быть идентифицированы рассматриваемая система, объект интереса и его предполагаемое окружение и включены дополнительные сведения, определенные в проекте и/или в организации. Примерами являются: дата выпуска и статус; авторы, рецензенты, утверждающие стороны, выпускающая описание архитектуры организация; история изменений; резюме; область применения; контекст; глоссарий; результаты любых оценок архитектуры или описания архитектуры, информация о контроле версий описания архитектуры; информация по управлению конфигурацией и справочная информация (см. ГОСТ Р 58609).

6.2 Идентификация заинтересованных сторон, их интересов, позиций и учитываемых аспектов

В описании архитектуры должны быть идентифицированы заинтересованные стороны системы, интересы которых соответствуют цели описания архитектуры и являются основополагающими для описания объекта интереса. В описании архитектуры отражению подлежат принципиальные позиции заинтересованных сторон по стратегическим, организационным, эксплуатационным, логическим, физическим и технологическим вопросам архитектуры системы, а также соответствующие структурные, организационные, научно-методические, поведенческие, функциональные и программно-технические аспекты, существенные для архитектуры системы.

Описание архитектуры должно определять возможное влияние архитектуры на текущие и будущие заинтересованные стороны.

В описании архитектуры должны быть учтены и, если применимо, определены интересы, связанные с целями системы и приемлемостью архитектуры для их достижения, с выполнимостью создания и развертывания системы, осуществимостью реализации и эксплуатации объекта интереса, потенциальными рисками и воздействиями системы на заинтересованные стороны на протяжении ее жизненного цикла, с вопросами сопровождения и развития системы. В описание архитектуры необходимо включить данные о существующих ограничениях ресурсов или иных ограничениях, в силу которых в описании архитектуры не удалось в должной мере учесть какие-либо интересы и позиции заинтересованных сторон и соответствующие аспекты. Несоответствия следует выявлять и обоснованно объяснять.

Описание архитектуры должно увязывать каждый интерес с конкретными заинтересованными сторонами, имеющими такой интерес.

Примечания

1 В общем случае взаимоувязывание интересов с заинтересованными сторонами представляет собой соотношение «многие ко многим».

2 Настоящий стандарт не предписывает степени детализации интересов, каким образом интересы находятся во взаимосвязи с другими интересами или как интересы соотносятся с другими вопросами системы, такими, например, как потребности заинтересованных сторон, цели системы или требования.

6.3 Учет архитектурных представлений и точек зрения на архитектуру

Описание архитектуры должно включать только одно архитектурное представление для каждой используемой точки зрения на архитектуру.

Описание архитектуры должно включать каждую используемую в нем точку зрения на архитектуру или ссылаться на нее. Каждая точка зрения на архитектуру должна содержать идентификатор версии, как это определено организацией и/или проектом. Каждый интерес, выявленный в соответствии с 6.2, должен быть выражен в виде по меньшей мере одной точки зрения на архитектуру. Каждая позиция заинтересованных сторон, определенная в 6.2, должна быть связана с соответствующими точками зрения на архитектуру. Каждая учтенная точка зрения на архитектуру должна быть определена в соответствии с условиями раздела 8. Каждый интерес, определенный в соответствии с 6.2, должен быть структурирован по крайней мере одной точкой зрения.

Архитектурное представление должно придерживаться главной точки зрения на архитектуру.

Примечание - Для функциональных точек зрения можно описать несколько видов архитектурного представления: например, функциональные цепочки будут отражать поведение, а деревья функций — декомпозицию.

Архитектурное представление должно содержать или предоставлять ссылку на:

• идентификационную и дополнительную информацию, предусмотренную организацией и/или проектом;
• главную точку зрения на архитектуру;
• один или несколько компонентов архитектурного представления, охватывающих все интересы, которые определяются главной точкой зрения на архитектуру, и некоторые или все объекты интереса, связанные с этой точкой зрения;
• записи любых определенных проблем архитектурного представления относительно главной точки зрения на архитектуру.

Описание архитектуры может включать другую информацию, которая не входит в какое-либо архитектурное представление — например, анализ объекта интереса, архитектурные принципы, архитектурные схемы, стили архитектуры, применение которых охватывает более одного представления, а также типовые базовые архитектурные решения, такие как эталонные архитектуры или архитектуры, специфичные для конкретной прикладной области, связи между представлениями и обоснование архитектуры.

6.4 Учет архитектурных моделей и компонентов архитектурного представления

Архитектурное представление должно состоять из одного или нескольких компонентов в соответствии с его главной точкой зрения на архитектуру, в качестве компонента может выступать архитектурная модель.

Каждый компонент представления должен содержать идентификатор версии, как это задается организацией и/или проектом, определять свой основной вид модели и придерживаться соглашений относительно главной точки зрения на архитектуру.

В рамках представления один или несколько компонентов могут использоваться для выборочного отражения части или всей информации, требуемой согласно точки зрения на архитектуру, для выделения интересующих моментов. Компонент может быть частью более чем одного архитектурного представления.

Если у компонента представления имеется фрагмент информации, не описанный моделью, следует добавить в описание архитектуры описание компонента представления для определения соглашений, используемых в этом компоненте.

Примечания

1 Распределение компонентов между представлениями архитектуры разрешает описанию архитектуры структурировать различные связанные интересы без избыточности или повторения той же самой информации во множественных представлениях и уменьшает возможности для несогласованности. Распределение компонентов также разрешает объектно-ориентированный стиль описания архитектуры. Так, архитектурные модели, распределенные по архитектурному представлению, могут использоваться для выражения архитектурных позиций. А компоненты, распределенные в пределах архитектурного представления, могут использоваться для выражения структуры архитектуры. Компоненты могут использоваться как «контейнеры» для применения архитектурных схем или стилей архитектуры, чтобы выражать основные схемы в пределах представлений архитектуры. Например, это могут быть послойные, трехъярусные, децентрализованные схемы, схемы «модель — представление — контролер».

2 Настоящий стандарт не описывает того, как создаются компоненты.

6.5 Отражение архитектурных связей

6.5.1 Связи в пределах описания архитектуры

В описание архитектуры следует включать анализ связей архитектурных компонентов и представлений. Описание архитектуры должно содержать также записи любых выявленных рассогласованностей, выражаемых через архитектурные компоненты и представления.

Связи и правила отражения связи могут быть использованы для того, чтобы выразить, осуществить записи, провести в жизнь и проанализировать связи между компонентами, представлениями и другими элементами в пределах описания архитектуры.

6.5.2 Связи

Каждая связь в описании архитектуры должна быть определена и описана с использованием элементов описания архитектуры.

Элементы описания архитектуры могут быть любыми конструкциями, установленными в 5.2 - 5.6 (заинтересованные стороны, интересы системы, точки зрения архитектуры, архитектурные представления, виды моделей, архитектурные модели, архитектурные решения и обоснования). Дополнительные виды элементов описания архитектуры могут быть введены после того, как определены точки зрения на архитектуру и виды моделей.

Примечание - Связь может быть определена между описаниями архитектуры, элемента и непосредственно между элементами.

6.5.3 Правила отражения связи

Описание архитектуры должно включать относящиеся к нему правила отражения связи.

Примечание - Правила отражения связи, применимые к описанию архитектуры, могут появляться в описании архитектуры применительно к конкретной точке зрения или структуре архитектуры или языку описания архитектуры.

Каждое определенное правило отражения связи следует задокументировать, а при изменениях провести документирование всех выявленных изменений.

Правило отражения связи считается корректным, если соответствующая связь может быть для него продемонстрирована. Правило отражения связи считается нарушенным, если соответствующая связь отсутствует или не может быть продемонстрирована для выполнения этого правила.

Примечание — Связи и правила отражения связи могут быть применены к множественным описаниям архитектуры, чтобы выразить отношения, касающиеся множественных архитектур или систем. Обобщая элемент описания архитектуры к другим информационным объектам, проект и/или организация могут использовать связи между описаниями архитектуры и другими рабочими продуктами (например такими, как спецификации требований), чтобы выразить другие отношения архитектурного интереса — например такие, как прослеживаемость элементов описания архитектуры к требованиям.

6.6 Документирование

6.6.1 Документирование обоснования архитектуры

Описание архитектуры должно содержать или ссылаться на обоснование для каждой точки зрения на архитектуру, включенной для применения в терминах заинтересованных сторон, их интересов, видов моделей, нотаций и методов.

Описание архитектуры должно включать обоснование для каждого решения, которое было рассмотрено применительно к основному решению архитектуры, или ссылаться на него. Описание архитектуры должно документировать рассмотренные и отвергнутые альтернативные решения, а также обоснование принятого решения.

В описание архитектуры следует включать свидетельство рассмотрения альтернатив и обоснования для сделанных выборов или ссылаться на них.

6.6.2 Документирование решений

Для описания архитектуры следует осуществлять документирование решений архитектуры, которые рассматривались применительно к основному решению архитектуры системы.

Задокументированное решение и соответствующую стратегию следует применять для установления критерия выбора основных решений, которые должны быть задокументированы и поддержаны обоснованием в описании архитектуры. Среди прочего следует рассматривать решения:

• относительно архитектурно существенных требований;
• требующие больших инвестиционных усилий или времени для их формирования, реализации или внедрения;
• воздействующие на основные заинтересованные стороны или множество заинтересованных сторон;
• отвечающие основополагающим интересам (таким как качество, безопасность, эффективность применения, способность к развитию);
• требующие сложного или неочевидного умозаключения;
• которые очень чувствительны к изменениям;
• которые могут быть дорогостоящими для модификации;
• которые формируют основу для планирования и управления проектом (например, разработка структуры разделения работ, создание цепочки поставок, прослеживание качества при реализации решений);
• которые приводят к капиталовложениям или косвенным затратам;
• связанные с соблюдением нормативно-правовых требований и договорных обязательств;
• связанные с устранением уязвимостей системы.

При документировании решений следует учитывать:

• уникальность применяемого подхода к выработке решения;
• четкость формулирования решения;
• лицо или орган, принимающие решение;
• ограничения, допущения и предположения, влияющие на решение;
• связь решения с интересами или аспектами сущности, к которым оно относится;
• связь решения с элементами описания архитектуры, которые затрагивает решение;
• ссылки на обоснование решения;
• связи с другими решениями;
• последствия использования решения (в отношении других решений);
• время, когда было принято, утверждено или изменено решение;
• ссылки на источники дополнительной информации.

Примечания

1 Рекомендуется осуществлять документирование рассмотренных и отклоненных альтернатив с обоснованием решений для этих отклонений. В будущем может оказаться, что приведенные причины отклонения более неактуальны и решение должно быть пересмотрено.

2 Рекомендуется осуществлять документирование взаимосвязей между решениями архитектуры.

7 Рекомендации по структуре и языку описания архитектуры

7.1 Рекомендации по структуре описания архитектуры

Структура описания архитектуры должна включать или ссылаться:

• на информацию, определяющую структуру описания архитектуры и предполагаемую область ее применения;
• идентификатор версии структуры описания архитектуры, определенной организацией и/или проектом;
• одну или несколько заинтересованных сторон и один или более типовых интересов в предполагаемой области применения описания архитектуры;
• одну или несколько точек зрения на архитектуру, которые охватывают эти типовые интересы в предполагаемой области применения описания архитектуры.

Структура описания архитектуры должна определять:

• одну или несколько позиций заинтересованных сторон;
• один или несколько аспектов;
• один или несколько формализованных методов структурирования точек зрения;
• один или несколько видов моделей, которые соответствуют установленным точкам зрения на архитектуру;
• описания, применимые к установленным точкам зрения на архитектуру;
• языки описания архитектуры, которые могут быть использованы для создания представлений в соответствии со спецификацией точки зрения на архитектуру;
• методы отражения связей;
• методы формирования представлений;
• идентификатор версии, определенный организацией и/или проектом.

Предполагаемая область использования структуры описания архитектуры может варьироваться от предельно общей (все отрасли и области применения, все виды объектов интереса, использование структуры описания архитектуры для различных целей) до очень специализированной или частной (например, структура, охватывающая конкретную отрасль, сферу применения или вид структуры объекта интереса, конкретная структура объекта интереса на определенном этапе своего жизненного цикла или структура объекта интереса для конкретной цели). Эта классификация аналогична уровню абстрагирования и обобщения, описанному как формализация структуры в ГОСТ Р ИСО 15704.

Структура описания архитектуры должна быть согласована с условиями концептуальной модели согласно 5.1. Это требование может быть удовлетворено через метамодель, связи конструкций структуры с моделью согласно 5.1, текстовое изложение или иным способом.

Примечание - Описание архитектуры может придерживаться одной или более структур архитектуры или не придерживаться никаких структур. Если придерживаться нескольких структур, описание архитектуры влечет за собой согласование структур между определенными заинтересованными сторонами, интересами, точками зрения, видами и правилами связи в пределах ОА.

7.2 Рекомендации по языку описания архитектуры

Язык описания архитектуры должен включать или ссылаться:

• на идентификацию типичных проблем или аспектов, охватываемых языком описания архитектуры;
• идентификацию одного или нескольких методов представления, которые могут быть выбраны из языка описания архитектуры;
• один или несколько видов моделей, реализуемых языком описания архитектуры для формулирования соответствующих интересов или отражения соответствующих аспектов;
• любые точки зрения на архитектуру, реализуемые с использованием языка описания архитектуры;
• любые правила отражения связи;
• идентификатор версии, определенный организацией и/или проектом.

8 Рекомендации по точке зрения на архитектуру, моделям и методам

8.1 Рекомендации по точке зрения на архитектуру

Точка зрения на архитектуру должна включать или ссылаться:

• на любые позиции заинтересованных сторон, связанные с этой точкой зрения;
• один или несколько интересов, определяемых данной точкой зрения на архитектуру;
• один или несколько аспектов, связанных с этими интересами;
• существующие типовые заинтересованные стороны, интересы которых определяются данной точкой зрения на архитектуру;
• виды моделей и описаний, используемых при формировании представлений;
• правила связи, фиксирующие отношения компонентов используемых представлений;
• ссылки на любые источники информации по этой точке зрения.

Спецификация точки зрения на архитектуру должна определять методы представления, используемые для создания, интерпретации и анализа представлений, управление которыми осуществляется посредством ассоциированной с ними точки зрения на архитектуру и одного или нескольких видов моделей.

Каждое описание должно помогать пользователям интерпретировать задокументированные компоненты представления. В спецификации точки зрения на архитектуру могут быть использованы правила связи.

Спецификация точки зрения на архитектуру может быть включена в состав ОА, спецификации структуры описания архитектуры или языка описания архитектуры или представлена в виде отдельного документа.

8.2 Рекомендации по спецификации вида модели

Спецификация вида модели должна включать или ссылаться:

• на соглашения, такие как определение языка описания архитектуры, нотации или способы моделирования, используемые для получения вида модели;
• методы представления точки зрения на архитектуру и правила связи, имеющие отношение к виду модели;
• идентификатор версии, определенный организацией и/или проектом;
• источники информации об этом виде модели.

Примечание - Для выполнения соглашений можно использовать различные способы, например метамодель, грамматику или схему для спецификации вида модели, который определяет структуру и интерпретацию его моделей.

8.3 Рекомендации по методам представления точки зрения на архитектуру

Спецификация точки зрения на архитектуру может включать один или несколько методов ее представления.

Методы представления определяют в спецификациях видов моделей, точках зрения, языке описания архитектуры и структуре описания архитектуры.

Если модель служит источником информации для формирования представления, то метод представления точки зрения на архитектуру должен определять способ отображения элементов описания архитектуры в компонентах представления, способ преобразования данных модели или их преобразования для использования в компонентах представления, а также способ представления связи между информацией из разных источников в компонентах представления.

Если при создании представления в качестве источника информации не используется какая-либо модель, то метод представления точки зрения на архитектуру должен определять способ отображения ее содержимого в компонентах представления в виде элементов описания архитектуры, способ их преобразования или преобразования данных, не связанных с моделью, для использования в компонентах представления, а также способ представления связи между информацией из разных источников в компонентах представления.

(справочное)

А.1 Введение

Описания архитектуры могут быть использованы в многообразии моделей жизненного цикла систем. Настоящее приложение иллюстрирует примеры того, как описания архитектуры, созданные в соответствии с настоящим стандартом, могут удовлетворять требованиям таких стандартов, как ГОСТ Р ИСО 15704, ГОСТ Р ИСО/МЭК 12207, ГОСТ Р 57193, ГОСТ Р ИСО/МЭК 10746-3. Общий подход для того, чтобы, используя настоящий стандарт, удовлетворять требованиям других стандартов, должен определить одну или более точек зрения, которые структурируют интересы системы, имеющие отношение к этим требованиям, и затем создают представления, удовлетворяющие этим требованиям как часть описания архитектуры.

А.2 Применение ГОСТ Р ИСО 15704

В ГОСТ Р ИСО 15704 определен типовой базовый набор понятий и принципов архитектурных сущностей, которые обеспечивают развитие предприятия, процессы интеграции и взаимодействия в его рамках, компьютерную обработку, а также установлены требования к моделям и языкам, созданным для выражения таких архитектур. В стандарте не представлены конкретные методы создания и использования архитектур и моделей предприятия. Однако этот стандарт может быть использован в качестве словаря терминов и общего описания архитектуры. Основное внимание уделяется созданию эталонной базы, пригодной для использования в конкретных корпоративных программах. Стандарт определяет обширный набор потенциальных артефактов для выражения архитектуры предприятия и связанных с ней методов.

Подход, принятый в ГОСТ Р ИСО 15704, заключается в использовании системного мышления и теории систем в архитектуре предприятия и в том, как на основе единой всеобъемлющей структуры можно согласовать и понять взаимодействие двух основных направлений изменения предприятия: в системной инженерии предприятия и в эволюционных изменениях.

ГОСТ Р ИСО 15704 посвящен архитектуре полного жизненного цикла объектов в контексте предприятия и поддерживает архитектуру, основанную на моделях и на структуре, используемой для организации этих моделей. Система моделирования предоставлена средствами измерения в соответствии:

• с уровнем абстракции модели — уровнем охвата идентификации, основных понятий, требований, предварительного архитектурного проектирования, детального проектирования, создания/внедрения, эксплуатации и вывода из эксплуатации;
• типами информации и аспектами сущности, передаваемых моделью (в части функций, информации, ресурсов и организации) и характеризующих точки зрения в рамках всех уровней абстракции;
• объемом охватываемой информации в моделях;
• средствами реализации моделей, описывающих компоненты сущности и реализованных с участием людей посредством применяемых технологий.

Кроме того, ГОСТ Р ИСО 15704 предлагает классификацию моделей от типовой до специфической.

Пример структуры моделирования приведен на рисунке А.1 (см. ГОСТ Р ИСО 15704-2022, приложение B).

Использование подхода, изложенного в ГОСТ Р ИСО 15704, поможет избежать многих проблем, возникающих при сопоставлении представлений в случае, когда используются исключительно описательные архитектурные представления.

Еще одна характерная особенность подхода — использование рекурсий и итераций для управления сложными отношениями. На рисунке А.2 показано рекурсивное использование описаний архитектуры для итерации этапов моделирования жизненного цикла.

А.3 Использование ГОСТ Р ИСО/МЭК 12207

В ГОСТ Р ИСО/МЭК 12207 приведены положения по проектированию архитектуры системы и отдельно — для программных средств. Специфично то, что проектирование архитектуры системы должно включать определение объектов аппаратных средств, программных средств и объектов ручных операций, включенных в систему, и распределение системных требований по этим объектам. Проектирование архитектуры системы должно быть оценено на соответствие критериям прослеживаемости и согласованности с требованиями к системе, приемлемости стандартов и методов проектирования и выполнимости программных и ручных операций в системе.

Ожидаемое использование описания архитектуры может включать другие процессы, определенные в ГОСТ Р ИСО/МЭК 12207. В частности, описание архитектуры может использоваться в других действиях помимо деятельности по проектированию архитектуры системы, например чтобы облегчить связь между приобретающей стороной и разработчиком.

Процесс проектирования архитектуры программного средства согласно ГОСТ Р ИСО/МЭК 12207 иллюстрирует декомпозиционный подход к архитектуре. Его первичная цель состоит в декомпозиции объектов программных средств системы в компоненты и последующем распределении требований по этим компонентам.

Описание архитектуры может соответствовать настоящему стандарту и ГОСТ Р ИСО/МЭК 12207. У общего подхода к «совместному соответствию» должна быть точка зрения, которая специально сфокусирована на производстве архитектурной продукции согласно ГОСТ Р ИСО/МЭК 12207.

Точка зрения декомпозиции и распределения согласно ГОСТ Р ИСО/МЭК 12207 структурирует следующие интересы:

• определение системных требований;
• декомпозицию системы на объекты;
• распределение требований по объектам;
• верификацию того, что все требования распределены по объектам.

Каждое требование определяется единственным образом. В случае необходимости требования декомпозируются и расширяются в производные требования для обеспечения полного множества требований для системы.

Система декомпозируется во множество объектов, где каждый объект — это объект аппаратных средств, программных средств или объект ручных операций. Также определяются взаимодействия между объектами.

Требования системы распределяются между объектами таким образом, чтобы каждый объект удовлетворял одному или более требованиям, и каждое требование распределялось как минимум по одному объекту.

В итоге начальной декомпозиции и распределения производится множество объектов с распределенными требованиями. Это описано в ГОСТ Р ИСО/МЭК 12207 в терминах процесса проектирования архитектуры системы.

Программные средства декомпозируются в зависимые компоненты. Требования, распределенные по каждому объекту программных средств, далее распределяются по одному или более компонентам. Описания интерфейса обеспечиваются между программными компонентами, между программными компонентами и аппаратными объектами и объектами ручного оперирования. Это описано в терминах проектирования архитектуры программных средств.

А.4 Использование ГОСТ Р 57193

В ГОСТ Р 57193 определен один процесс, специально имеющий отношение к архитектуре, — это определения архитектуры. Понятие архитектуры в настоящем стандарте совместимо с процессом проектирования архитектуры согласно ГОСТ Р 57193, в котором изложены требования к описанию архитектуры в дополнение к требованиям настоящего стандарта. Специфично то, что определение архитектуры по ГОСТ Р 57193 должно предусматривать определение системных элементов, включенных в систему, и распределение требований системы по этим элементам.

Ожидаемое использование описания архитектуры может включать другие процессы из ГОСТ Р 57193. В частности, описание архитектуры допустимо использовать в других действиях кроме деятельности по определению архитектуры системы, например для облегчения связи между приобретающей стороной и разработчиком (поставщиком).

Описание архитектуры может соответствовать настоящему стандарту и ГОСТ Р 57193. У общего подхода к «совместному соответствию» должна быть точка зрения, которая специально сосредотачивается на производстве архитектурной продукции согласно ГОСТ Р 57193.

Точка зрения декомпозиции по ГОСТ Р 57193 структурирует следующие интересы:

• определение системных требований;
• декомпозицию системы на системные элементы;
• распределение требований по системным элементам;
• верификацию того, что все требования распределены по системным элементам.

Каждое требование определяется единственным образом. В случае необходимости требования декомпозируются и расширяются в производные требования для обеспечения полного множества требований для системы.

Также определяются взаимодействия между системными элементами.

Требования системы распределяются между системными элементами таким образом, чтобы каждый системный элемент удовлетворял одному или более требованиям, и каждое требование распределялось как минимум по одному системному элементу.

В итоге начальной декомпозиции и распределения производится множество системных элементов с распределенными требованиями. Это определено в терминах описания архитектуры системы.

А.5 Использование со стандартами открытой распределенной обработки

Эталонная модель открытой распределенной обработки определяет структуру архитектуры для систем распределенной обработки.

Структура эталонной модели определяет пять точек зрения для того, чтобы определить системы открытой распределенной обработки и ряд связей между ними.

Для каждой точки зрения существует соответствующий язык точки зрения, который определяет понятия и правила для определения системы открытой распределенной обработки с соответствующей точкой зрения.

Описание архитектуры, соответствующее настоящему стандарту и использующее ГОСТ Р ИСО/МЭК 10746-3, может включать точки зрения, определенные ГОСТ Р ИСО/МЭК 10746-3, и представления о реализации этих точек зрения. Необязательно ограничиваться пятью точками зрения, определенными в ГОСТ Р ИСО/МЭК 10746-3 для соответствующего описания архитектуры. При необходимости описание архитектуры может включать дополнительные точки зрения и представления.

Элементы спецификации, определенной для описания архитектуры (такие, как заинтересованные стороны), в ГОСТ Р ИСО/МЭК 10746-3 опущены, так как этот стандарт во многом ориентирован на индивидуальные системы для предпринимателей.

Предпринимательская точка зрения (точка зрения предприятия) структурирует следующие интересы:

• цель, область применения и политику для системы открытой распределенной обработки;
• роли, выполняемые системой;
• действия, совершаемые системой;
• положения политики о системе.

На предпринимательском языке система открытой распределенной обработки и ее окружающая среда представляются как сообщество объектов. Определение сообщества приведено в терминах:

• предпринимательских объектов (объектов предприятия), включающих сообщество;
• ролей, выполняемых каждым из этих объектов;
• политики, управляющей взаимодействиями между предпринимательскими объектами (объектами предприятия), выполняющими роли;
• политики, управляющей созданием, использованием и удалением ресурсов с помощью предпринимательских объектов (объектов предприятия), выполняющих роли;
• политики, управляющей конфигурацией предпринимательских объектов (объектов предприятия) и назначением ролей к объектам;
• политики, относящейся к контрактам по окружающей среде, управляющим системой.

Примечания

1 Роли ограничивают поведение объектов, их выполняющих.

2 Политики определены в терминах разрешений, обязательств и запрещений.

3 Предпринимательский язык (язык предприятия) определен в ГОСТ Р ИСО/МЭК 15414.

В качестве примеров ниже рассмотрены также информационная, вычислительная, инженерная, технологическая точки зрения.

Информационная точка зрения структурирует интересы в виде семантик информации и обработки информации в системе открытой распределенной обработки.

Информационный язык определен в терминах трех схем:

• инвариантной: предикаты на объектах, которые всегда должны быть в состоянии «верно» («true»);
• статической: состояния одного или более объектов в некоторый момент времени;
• динамической: изменения допустимого состояния одного или более объектов.

Вычислительная точка зрения структурирует интересы в виде функциональной декомпозиции системы на объекты, которые взаимодействуют на уровне интерфейсов.

Вычислительный язык охватывает понятия для определения:

• вычислительных объектов;
• интерфейсов для объектов и определения интерфейсов;
• взаимодействия в интерфейсах в виде операций или непрерывных потоков;
• неявных и явных связываний и объектов составного связывания.

Инженерная точка зрения структурирует интересы в виде механизмов и функций, требуемых для поддержки распределенного взаимодействия между элементами в системе.

Инженерный язык включает понятия для определения:

• конфигурации объектов инженерии в целях управления, например для ресурсов, защиты и срабатывания механизмов;
• структуры каналов связи, которые соединяют объекты инженерии в терминах заглушек, связи, протоколов и перехватов;
• схемы для обеспечения требуемой прозрачности, например прозрачности доступа, отказа, положения, постоянства, перемещения, дублирования, транзакции.

Технологическая точка зрения структурирует интересы в виде выбора реализуемых стандартов для системы, их реализации и тестирования.

Технологический язык включает понятия:

• охвата выбора технологии для их использования в терминах отбора существующих стандартов или проблемно-ориентированных спецификаций для этих технологий;
• выражения того, как реализованы спецификации для системы открытой распределенной обработки;
• оказания поддержки при тестировании и испытаниях.

(справочное)

Описания архитектуры применяют в рамках широкого спектра условий и моделей жизненного цикла. В данном приложении приведены примеры целей применения описания архитектуры на протяжении всего жизненного цикла объекта интереса. Описания архитектуры могут быть применены для достижения следующих целей в жизненном цикле системы:

• для создания структурных основ обеспечения деятельности по проектированию и модернизации;
• использования при проведении анализа и оценки альтернативных вариантов архитектуры;
• использования в качестве документации по разработке, поддержке и сопровождению;
• поддержки обоснованных технических, инвестиционных или иных стратегических решений;
• снижения сопутствующих рисков или их удержания в допустимых пределах;
• документирования основных характеристик объекта, таких как: - архитектурные решения, их обоснования и последствия; - предполагаемое использование и окружающая среда; - принципы, допущения и ограничения, которыми следует руководствоваться при реализации будущих изменений; - точки адаптации или ограничения системы применительно к будущим изменениям; - документирование архитектурных стилей;
• использования в качестве источника данных для автоматизированных инструментариев моделирования, создания и анализа систем;
• определения группы или семейства сущностей с общими характеристиками (например, это может быть задумано как эталонная архитектура, эталонная модель или архитектура линейки продуктов);
• коммуникации между сторонами, участвующими в разработке, производстве, внедрении, эксплуатации и обслуживании объекта интереса, при доведении информации от проектировщиков архитектуры и систем до разработчиков;
• использования в качестве основы при подготовке документов по приобретению (например, при разработке технических заданий, подготовке запросов на приобретение);
• коммуникации между заказчиками, приобретающими сторонами, поставщиками (разработчиками) и пользователями в рамках переговоров по договору;
• документирования характеристик, особенностей и конструктивных элементов сущностей в интересах потенциальных заказчиков, приобретающих сторон, владельцев, операторов и интеграторов;
• планирования перехода от устаревшей архитектуры к новой;
• использования в качестве руководства по поддержке эксплуатационных процессов и инфраструктуры и управлению конфигурацией;
• информационной поддержки при планировании, составлении календарных графиков и бюджетировании на протяжении всего жизненного цикла;
• установления критериев при сертификации реализованных систем на соответствие требованиям к архитектуре;
• использования в качестве информационной поддержки обеспечения соответствия технической политике (например, в части соответствия законодательству или общим архитектурным принципам, принятым руководством);
• обзора, анализа и оценки конкретной сущности на протяжении ее жизненного цикла;
• анализа и оценки альтернативных архитектур;
• обмена опытом и повторного использования знаний об архитектуре через определение точек зрения на архитектуру, архитектурных схем и стилей;
• обучения заинтересованных сторон и других участников передовым практикам в области разработки и модификации архитектуры;
• использования в качестве доказательства функциональных и нефункциональных свойств какой-либо сущности;
• моделирования с использованием принятых сценариев.

Примечание — В приложении А рассмотрено использование описания архитектуры в контексте других стандартов.

(справочное)

Архитектура системы (или ее конкретной сущности, представляющей собой объект интереса) имеет свой жизненный цикл.

Потенциально архитектура влияет на выполняемые процессы на протяжении всего жизненного цикла системы. Архитектура объектов интереса также имеет свой жизненный цикл.

Описание архитектуры применяется в рамках широкого спектра условий и моделей жизненного цикла. Описание архитектуры является рабочим продуктом, получаемым в ходе процесса определения архитектуры для выражения сути архитектуры и связанных с ней решений, обмена этой информацией и ее документирования в течение всего жизненного цикла. Первоначальные и последующие (постепенные или масштабные) усилия по созданию архитектуры нацелены на передачу и документирование результатов использования описания архитектуры. Статус и история альтернативных решений и версий также могут быть выражены в виде описания архитектуры.

Разработанные модели и непосредственно сами описания архитектуры имеют свой собственный жизненный цикл. В ходе разработки архитектуры подлежат выполнению работы по определению ее необходимости, формулировке основных замыслов, детализации элементов, проведению анализа компромиссов и возможных вариантов реализации, а также по оценке, утверждению, подготовке к использованию и вводу в эксплуатацию выбранного варианта архитектуры. Впоследствии описание архитектуры может быть обновлено, т.е. появятся новые версии описания архитектуры. В идеальном случае этапы эксплуатации архитектуры системы являются длительными и стабильными.

Жизненный цикл любого объекта интереса во многом определяется жизненным циклом его архитектуры. К примеру, решения о вложении средств в проект по разработке системы услуг на основе существующих систем во многом определяются наличием стабильной, надежной, общей и согласованной архитектуры интегрирующей инфраструктуры. При планировании этапов жизненного цикла системы учитываются прогнозируемые этапы жизненного цикла выбранной архитектуры.

Процесс определения архитектуры включает в себя рассмотрение объекта интереса (в том числе системы в целом) с различных сторон, и эти точки зрения соответствуют деятельности на различных этапах жизненного цикла. Так, разработчик архитектуры будет рассматривать объект интереса с позиции бизнеса, охватывая его идентичность и концепцию (например, роль на рынке, возможности, взаимосвязь с контекстом бизнеса, а также политики и принципы, используемые для управления решением). Разработчик архитектуры должен провести анализ высокоуровневых требований, которым должна удовлетворять система (функциональные и нефункциональные), и подготовить спецификации архитектуры с позиции бизнес-аналитика. Далее эти требования подлежат преобразованию в архитектурное решение, которое должно быть оценено и формирует соответствующий элемент проекта системы.

Этапы — это определение идентичности, разработка концепции, определение требований, предварительное проектирование (см. ГОСТ Р ИСО 15704, ГОСТ Р 57193, ГОСТ Р ИСО/МЭК 12207) и так далее, пока не будут удовлетворены все интересы заинтересованных сторон. Таким образом, понятие «этап» относится к типу работ. Впоследствии эти работы повторяются по мере необходимости на различных этапах жизненного цикла системы или конкретного объекта интереса.

Необходимость в итерациях определяется множеством факторов, таких как инновационное содержание разрабатываемой архитектуры, навыки и зрелость организации, наличие эталонных архитектур или схем для повторного использования и применяемые методы.

Обычно разработка архитектуры ведется в организационном контексте проекта или программы, в этом случае программа и ее проекты также должны быть оформлены в архитектурном плане как самостоятельные сущности. То же самое относится к системам систем и системам поддержки (см. ГОСТ Р 57193, ГОСТ Р 57102). Каждая из них может быть реализована как система, архитектура которой также подлежит описанию.

В процессе создания архитектуры ее разработчики должны взаимодействовать с заинтересованными сторонами как для получения, так и для предоставления необходимой информации. Описания архитектуры подлежат реализации в форме, понятной как заинтересованным сторонам, так и разработчикам архитектуры, и удовлетворяющей цели архитектурного проектирования и различным системным процессам.

БИБЛИОГРАФИЯ