...

От требований к постановкам задач на разработку с помощью архитектурного проекта

курсы по системному и бизнес-анализу для начинающих, основы архитектуры и интеграции ИС для аналитика, проектирование архитектуры информационных систем, стандарты и практики описания архитектуры ИС примеры курсы обучение, обучение системных и бизнес-аналитиков основам архитектуры и интеграции ИС, Школа прикладного бизнес-анализа учебный центр Коммерсант

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

Требования vs постановки задач: в чем разница?

Согласно определению BABOK®Guide, требование представляет собой пригодное для практического использования представление решения в виде условия или возможности, которые необходимы стейкхолдеру для достижения цели, инициированной потребностью. Тот же самый свод знаний по бизнес-анализу отмечает, что потребность трансформируется в требование, которое далее преобразуется в проект решения (дизайн) – пригодное для практического использования представление решения с привязкой к конкретным технологиям.

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

Таким образом, полная спецификация требования к системе нужна для выработки проектных решений, из которых следуют постановки задач на реализацию. Например, требование «Сформировать квартальный отчет по продажам товаров спецкатегорий», доступное для роли Менеджер и детально описанное в форме Use Case с отсылкой к сущностям доменной (концептуальной) модели данных и их атрибутам, трансформируется в физическую модель базы данных и целый набор модулей в архитектурном проекте ИС. В свою очередь, эти архитектурные концепции уже реализуются в виде постановок задач разработчикам с привязкой к конкретным технологиям, которые используются командой и могут воплотить решение, отвечающее функциональным и нефункциональным требованиям, описанным в спецификации (ТЗ).

Чтобы наглядно показать эту трассировку, рассмотрим ее в виде таблицы. Предположим, есть ограничение, т.е. нефункциональное требование, к формату файла генерируемых отчетов в виде PDF-документов. Также выбор решения ограничен используемым стеком технологий: команда использует язык программирования Python и базу данных PostgreSQL, если эти инструменты могут удовлетворить все требования к разрабатываемой ИС. Тогда трассировка требований с компонентами архитектурного проектирования и постановками задач будет выглядеть следующим образом.

Требование Компонент архитектуры Постановка задачи
Сформировать квартальный отчет по продажам товаров спецкатегорий Таблицы Sale, Product в БД PostgreSQL (физическая модель данных со всеми таблицами, их атрибутами и межтабличными связями прилагается) Создать таблицы Sale, Product в БД с атрибутами и связями согласно прилагаемой физической схеме БД
Установить права на чтение данных из этих таблиц для пользовательской роли Manager
Модуль запросов БД Написать Python-скрипт, реализующий SQL-запрос на чтение данных из БД и возвращающий результат выполнения в функцию генерации отчетов
Модуль авторизации Написать Python-скрипт проверки наличия у пользователя прав на выполнение операции  с данными
Модуль генерации отчетов Сформировать pdf-файл отчета по корпоративному шаблону компании, используя Python-библиотеку с открытым исходным кодом pdfrw
Каждый отчет должен представлять собой PDF-файл

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

Разработка ТЗ на информационную систему по ГОСТ и SRS

Код курса
TTIS
Ближайшая дата курса
2 декабря, 2024
Продолжительность
16 ак.часов
Стоимость обучения
36 000 руб.

Что такое проектирование архитектуры: стандарты и практики

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

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

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

Если внимательно прочитать стандарт ГОСТ Р 57193-2016 и свод знаний SEBoK, можно узнать много интересного и полезного. Однако, как и любые рамочные документы, они систематизируют общие понятия без привязки к конкретным техникам и технологиям. В частности, остается неясным, как именно описывать архитектурное решение, чтобы поставить задачи на его реализацию. Еще один существующий стандарт, ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011 «Системная и программная инженерия. Описание архитектуры» также не содержит указания конкретных техник и шаблонов, которые должны использоваться при разработке архитектурного проекта. Хотя этот стандарт упоминает необходимость использования архитектурных представлений для отражения специфических точек зрения в виде структурных и поведенческих моделей, он не ссылается на конкретную нотацию. Впрочем, в тексте стандарта можно найти отсылку к языкам архитектурного моделирования ArchiMate, SysML и UML.

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

  1. схематичное описание контекста проектируемой ИС, в т.ч. акторов (пользователей и внешних сервисов), взаимодействующих с системой. Это удобно показать в виде UML-диаграммы Use Case или схемы контекста (схемы системного ландшафта) C4, о которой я рассказываю здесь и здесь.
  2. архитектурная категория распределенной системы, например, клиент-серверная монолитная или микросервисная. Здесь же отражаются поведенческие аспекты ИС, например, архитектура, управляемая событиями (EDA, Event Driven Architecture).
  3. структура элементов системы в виде UML-диаграммы компонентов или набора схем C4 уровня контейнеров и компонентов. Эти модели обычно отражают подходящие архитектурные паттерны, например, CQRS для разделения запросов на чтение и запись данных по разным хранилищам с их периодической синхронизацией, шлюз API для маршрутизации запросов по разным микросервисам и пр. Причем здесь важно показать не только непосредственный набор компонентов системы, которые напрямую связаны с ее функциональными и нефункциональными требованиями, но и «вспомогательные» элементы, такие как внешние сервисы или подключаемые плагины для мониторинга, резервного копирования, логирования, балансировки нагрузки, валидации входящих запросов, обеспечения безопасности и т.д.
  4. взаимодействие элементов архитектуры между собой и реакции в ответ на внешние события. Обычно это визуализируется в виде UML-диаграммы последовательности или похожей на нее динамической схемы C Здесь важно отразить синхронный или асинхронный порядок обмена сообщениями, а также выделить интерфейсы взаимодействия как точки обмена между системами и объектами.
  5. перечисление протоколов сетевого и межсистемного взаимодействия, в т.ч. по веб-API;
  6. описание форматов и схем данных, используемых в проектируемой ИС;
  7. перечень используемых технологий, в т.ч. хранилища данных (файловые, объектные, СУБД), языки программирования, фреймворки и библиотеки для разработки ПО. Главными критериями выбора здесь являются возможности этих технологий удовлетворить предъявляемые к системе функциональные и нефункциональные требования, включая вышеотмеченные пункты архитектурного проектирования. Также важно учитывать наличие у команды разработки релевантного опыта работы с этими технологиями и возможность их последующей эксплуатации.
  8. физические схемы моделей баз данных для выбранных СУБД, схемы сообщений, ограничения и подходящие конфигурации настройки компонентов системы;
  9. порядок реализации спроектированной архитектуры, основанный на технических зависимостях одних компонентов от других.

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

Основы архитектуры и интеграции информационных систем

Код курса
OAIS
Ближайшая дата курса
5 ноября, 2024
Продолжительность
16 ак.часов
Стоимость обучения
36 000 руб.

Как это сделать, я рассказываю на своих курсах Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:

 

Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.

Источники

  1. https://protect.gost.ru/document.aspx?control=7&id=204973
  2. https://protect.gost.ru/document.aspx?control=7&id=205413
  3. https://ru.wikipedia.org/wiki/Архитектура_системы
  4. https://ru.wikipedia.org/wiki/Архитектура_программного_обеспечения

Добавить комментарий