ГОСТ Р 70466—2022
В результате выполнения этого шага будут сформированы конкретные тестируемые требования,
упорядоченные по ролям, которые позволят создать архитектуру системы для удовлетворения потреб
ностей заинтересованных сторон. При этом каждый интерес должен соответствовать одному или не
скольким действиями, а каждое действие должно соответствовать одному или нескольким интересам.
Графическое представление/документирование информации зависит от степени детализации
конкретных действий и может оказаться невозможным. В этом случае архитектору следует учитывать
потребности пользователей при подготовке информации и форматировании данных для их представ
ления. Если применяется описанный выше подход, желательна дальнейшая декомпозиция подролей
на классы, которые, в свою очередь, соответствуют отдельным утверждениям о действиях. Этот про
цесс может быть очень полезным на следующем шаге, поскольку позволяет облегчить выбор функцио
нальных компонентов, поддерживающих несколько видов действий.
9.5 Определение функциональных компонентов для реализации деятельности
Если предыдущий шаг связан с частью анализа требований к разработке процессов жизненного
цикла системы/программного обеспечения, то данный шаг представляет собой фазу высокоуровневого
проектирования системы больших данных. В то же время функциональные уровни и классы функци
ональных компонентов в функциональном представлении эталонной архитектуры формируют органи
зационную структуру для конфигурационных элементов (программных или аппаратных), которые обе
спечивают построение архитектуры системы больших данных.
В начале данного шага должны быть выбраны соответствующие компоненты, с помощью которых
будут выполняться действия, определенные на предыдущем шаге. Компонентами могут быть инстру
менты, продукты или программные средства — существующие или новые, которые следует разрабо
тать с учетом необходимого набора действий. Уровень детализации, установленный на данном шаге,
зависит от архитектора и потребностей системы. При разработке крупномасштабных систем рекомен
дуется иерархически структурировать компоненты, организуя их в подсистемы внутри уровней.
Во всех случаях компоненты должны быть соотнесены с одним или несколькими действиями. Не
обходимо обратить внимание на отсутствие требования соответствия действия одному компоненту. В
зависимости от степени детализации задокументированных действий, возможно, для некоторых видов
деятельности потребуется несколько компонентов.
Для упрощения трассировки и сквозного процесса разработки, которые рассмотрены выше, долж
на быть принята стандартная номенклатура компонентов.
Интерфейсы между функциональными компонентами выходят за рамки рассматриваемого архи
тектурного представления и будут определены и специфицированы в процессе внедрения как состав ная
часть детализированной разработки.
В то же время в зависимости от используемого уровня детализации графическое представление
информации на одной диаграмме не всегда возможно, хотя для каждого уровня/многоуровневой функ
ции может быть разработан вариант графического представления. При этом в результате взаимодей
ствия уровней некоторая часть контекста может быть потеряна.
9.6 Соответствие сквозных действий/функциональных компонентов интересам
Это последний шаг процесса разработки, который включает валидацию того, что посредством
деятельности может быть выполнена трассировка любого требования до функционального компонента и
наоборот, трассировка каждого функционального компонента до интереса, при этом любая деятель ность
фактически присутствует в этих взаимосвязях.
Именно на этом шаге с целью эффективной валидации высокоуровневой архитектуры оказыва
ется важным выбор базы данных или других инструментов трассировки требований для сбора необхо
димой информации.
12