Аналитики часто отмечают, что разработчики не хотят читать большую спецификацию требований, а разработчики отвечают, что ТЗ выглядит слишком абстрактно и не годится для реализации. Такая ситуация возникает, когда между требованиями и постановками задач на реализацию пропущен важный этап проектирования, когда определяется архитектура системы и стек технологий для ее создания. Разбираемся, что должен в себя включать этот документ и почему существующие стандарты описания архитектуры не слишком помогают в его формировании.
Требования vs постановки задач: в чем разница?
Согласно определению BABOK®Guide, требование представляет собой пригодное для практического использования представление решения в виде условия или возможности, которые необходимы стейкхолдеру для достижения цели, инициированной потребностью. Тот же самый свод знаний по бизнес-анализу отмечает, что потребность трансформируется в требование, которое далее преобразуется в проект решения (дизайн) – пригодное для практического использования представление решения с привязкой к конкретным технологиям.
Будучи сфокусированном на потребности, требование пишется на универсальном языке и, по сути, представляет собой концепт удовлетворения бизнес-целей. Например, в спецификацию требований включается концептуальная модель данных, описывающая основные объекты домена и связи между ними. А ее реализация в виде физической модели для конкретной СУБД является проектным решением этого набора требований, включая показатели качества, которые должна обеспечивать информационная система. В частности, здесь я описывала пример перехода от доменного (концептуального) проектирования к физической реализации в PostgreSQL.
Таким образом, полная спецификация требования к системе нужна для выработки проектных решений, из которых следуют постановки задач на реализацию. Например, требование «Сформировать квартальный отчет по продажам товаров спецкатегорий», доступное для роли Менеджер и детально описанное в форме Use Case с отсылкой к сущностям доменной (концептуальной) модели данных и их атрибутам, трансформируется в физическую модель базы данных и целый набор модулей в архитектурном проекте ИС. В свою очередь, эти архитектурные концепции уже реализуются в виде постановок задач разработчикам с привязкой к конкретным технологиям, которые используются командой и могут воплотить решение, отвечающее функциональным и нефункциональным требованиям, описанным в спецификации (ТЗ).
Чтобы наглядно показать эту трассировку, рассмотрим ее в виде таблицы. Предположим, есть ограничение, т.е. нефункциональное требование, к формату файла генерируемых отчетов в виде PDF-документов. Также выбор решения ограничен используемым стеком технологий: команда использует язык программирования Python и базу данных PostgreSQL, если эти инструменты могут удовлетворить все требования к разрабатываемой ИС. Тогда трассировка требований с компонентами архитектурного проектирования и постановками задач будет выглядеть следующим образом.
| Требование | Компонент архитектуры | Постановка задачи | |
| Сформировать квартальный отчет по продажам товаров спецкатегорий | Таблицы Sale, Product в БД PostgreSQL (физическая модель данных со всеми таблицами, их атрибутами и межтабличными связями прилагается) | Создать таблицы Sale, Product в БД с атрибутами и связями согласно прилагаемой физической схеме БД | |
| Установить права на чтение данных из этих таблиц для пользовательской роли Manager | |||
| Модуль запросов БД | Написать Python-скрипт, реализующий SQL-запрос на чтение данных из БД и возвращающий результат выполнения в функцию генерации отчетов | ||
| Модуль авторизации | Написать Python-скрипт проверки наличия у пользователя прав на выполнение операции с данными | ||
| Модуль генерации отчетов | Сформировать pdf-файл отчета по корпоративному шаблону компании, используя Python-библиотеку с открытым исходным кодом pdfrw | ||
| Каждый отчет должен представлять собой PDF-файл |
Однако, аллокация, т.е. распределение требований по компонентам архитектуры, является лишь одним из этапов архитектурного проектирования. Кроме определения структуры информационной системы, также необходимо определить, каким образом эти компоненты будут связаны друг с другом, чтобы удовлетворить предъявляемый набор требований. Для этого проектировщик ИС использует соответствующие архитектурные шаблоны (паттерны). Некоторые из них мы рассмотрим далее, а также поговорим про стандарты и практики описания архитектуры ИС.
Разработка ТЗ на информационную систему по ГОСТ и SRS
Код курса
TTIS
Ближайшая дата курса
3 июня, 2024
Продолжительность
12 ак.часов
Стоимость обучения
27 000 руб.
Что такое проектирование архитектуры: стандарты и практики
Согласно ГОСТ Р 57193-2016 «Системная инженерия — Процессы жизненного цикла систем», который в т.ч. описывает процесс проектирования архитектуры, под архитектурой системы понимается принципиальная организация системы, воплощенная в её элементах, их взаимоотношениях друг с другом и со средой, а также принципы, направляющие её проектирование и эволюцию. Результат проектирования архитектуры представляет собой проект решения, удовлетворяющего функциональным и нефункциональным требованиям. Такой архитектурный проект, оформленный в виде соответствующего документа (спецификации), может быть представлен в форме эскизов, рисунков или других видов описаний.
В свою очередь, свод знаний по системной инженерии (SEBoK) выделяет логическую и физическую архитектуру системы:
- логическая архитектура состоит из набора функций (функциональная архитектура), сценарии их работы и взаимодействия, включая интерфейсы (поведенческая архитектура), а также определение синхронных и асинхронных аспектов функций (временная архитектура).
- физическая архитектура воплощает концепции логической архитектуры с помощью конкретных элементов системы и физических интерфейсов, которые реализуют спроектированные решения.
Если внимательно прочитать стандарт ГОСТ Р 57193-2016 и свод знаний SEBoK, можно узнать много интересного и полезного. Однако, как и любые рамочные документы, они систематизируют общие понятия без привязки к конкретным техникам и технологиям. В частности, остается неясным, как именно описывать архитектурное решение, чтобы поставить задачи на его реализацию. Еще один существующий стандарт, ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011 «Системная и программная инженерия. Описание архитектуры» также не содержит указания конкретных техник и шаблонов, которые должны использоваться при разработке архитектурного проекта. Хотя этот стандарт упоминает необходимость использования архитектурных представлений для отражения специфических точек зрения в виде структурных и поведенческих моделей, он не ссылается на конкретную нотацию. Впрочем, в тексте стандарта можно найти отсылку к языкам архитектурного моделирования ArchiMate, SysML и UML.
Если наложить все важные концепции, изложенные в стандарте описания архитектуры, на практический опыт, то документ архитектурного проекта должен включать, как минимум, следующие аспекты:
- схематичное описание контекста проектируемой ИС, в т.ч. акторов (пользователей и внешних сервисов), взаимодействующих с системой. Это удобно показать в виде UML-диаграммы Use Case или схемы контекста (схемы системного ландшафта) C4, о которой я рассказываю здесь и здесь.
- архитектурная категория распределенной системы, например, клиент-серверная монолитная или микросервисная. Здесь же отражаются поведенческие аспекты ИС, например, архитектура, управляемая событиями (EDA, Event Driven Architecture).
- структура элементов системы в виде UML-диаграммы компонентов или набора схем C4 уровня контейнеров и компонентов. Эти модели обычно отражают подходящие архитектурные паттерны, например, CQRS для разделения запросов на чтение и запись данных по разным хранилищам с их периодической синхронизацией, шлюз API для маршрутизации запросов по разным микросервисам и пр. Причем здесь важно показать не только непосредственный набор компонентов системы, которые напрямую связаны с ее функциональными и нефункциональными требованиями, но и «вспомогательные» элементы, такие как внешние сервисы или подключаемые плагины для мониторинга, резервного копирования, логирования, балансировки нагрузки, валидации входящих запросов, обеспечения безопасности и т.д.
- взаимодействие элементов архитектуры между собой и реакции в ответ на внешние события. Обычно это визуализируется в виде UML-диаграммы последовательности или похожей на нее динамической схемы C Здесь важно отразить синхронный или асинхронный порядок обмена сообщениями, а также выделить интерфейсы взаимодействия как точки обмена между системами и объектами.
- перечисление протоколов сетевого и межсистемного взаимодействия, в т.ч. по веб-API;
- описание форматов и схем данных, используемых в проектируемой ИС;
- перечень используемых технологий, в т.ч. хранилища данных (файловые, объектные, СУБД), языки программирования, фреймворки и библиотеки для разработки ПО. Главными критериями выбора здесь являются возможности этих технологий удовлетворить предъявляемые к системе функциональные и нефункциональные требования, включая вышеотмеченные пункты архитектурного проектирования. Также важно учитывать наличие у команды разработки релевантного опыта работы с этими технологиями и возможность их последующей эксплуатации.
- физические схемы моделей баз данных для выбранных СУБД, схемы сообщений, ограничения и подходящие конфигурации настройки компонентов системы;
- порядок реализации спроектированной архитектуры, основанный на технических зависимостях одних компонентов от других.
Подробное описание всех этих и, возможно еще других дополнительных аспектов архитектуры, позволяет сформировать четкие, точные, отслеживаемые и проверяемые постановки задач на реализацию требований к ИС. Про другие артефакты аналитика и техники их разработки читайте в моей новой статье.
Основы архитектуры и интеграции информационных систем
Код курса
OAIS
Ближайшая дата курса
20 мая, 2024
Продолжительность
12 ак.часов
Стоимость обучения
27 000 руб.
Как это сделать, я рассказываю на своих курсах Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
- Основы архитектуры и интеграции информационных систем
- Разработка ТЗ на информационную систему по ГОСТ и SRS
Источники
