9.4 Разработка подробных описаний деятельности и ее соответствие интересам (Проект ГОСТ ИТ БД Структура и процесс применения)

From Стандартопедия
Jump to navigation Jump to search


9.4 Разработка подробных описаний деятельности и ее соответствие интересам

На данном шаге определяется деятельность системы или архитектуры. На основе эталонной архитектуры больших данных, представленной в категориях ролей и подролей, создаются механизмы для сбора и организации результатов реализации процессов системной и программной инженерии. При выполнении этого шага группа разработчиков должна опираться на положения стандарта ИСО/МЭК 29148:2011 «Системная и программная инженерия. Процессы жизненного цикла. Разработка требований» . Этот стандарт поможет трансформировать описанные выше проблемы в конкретные и тестируемые требования.

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

<Роль или подроль> должна <глагол><объект>

Роль или подроль обозначают субъект, модальность и глагол — предикат, а также объект — предмет, над которым выполняется действие. В 3-й части ИСО/МЭК 20547-3 подробно описываются классы действий, которые должны выполняться системами.

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

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

– сервис-провайдер сбора коллекций больших данных должен подтверждать соответствие данных XXX стандарту YYYY;

– сервис-провайдер визуализации больших данных должен представлять результаты в виде ориентированного графа;

– сервис-провайдер доступа к большим данным должен фиксировать доступ пользователя к системе.

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

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

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

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