В первой статье цикла анализировалась методология заказной разработки, принятой в компании IBS, и предпосылки ее создания. В продолжении рассматриваются процессы выявления требований и проектирования архитектуры информационных систем. Рассказывают начальник отдела аналитики Дмитрий Шумов и системный архитектор Алексей Пыжов.
Процесс построения бизнес-архитектуры и сопутствующий ему сбор требований направлены на создание полного, точного и согласованного представления о потребностях бизнеса, которое служит основой для проектирования и разработки будущей информационной системы.
Эти процессы обеспечивают понимание текущей ситуации, определяют имеющиеся проблемы, а также формируют согласованные требования для будущей системы, что существенно повышает шансы успешной реализации проекта за счет четкого понимания задач и целей.
Отправной точкой являются исходные требования бизнеса, которые могут быть представлены в виде концепции (выраженной в явном или неявном виде), верхнеуровневых бизнес-требований или технического задания.
Тем не менее в любом проекте есть этап сбора требований, в качестве основных методов в котором используют:
Для описания требований и моделирования применяются такие инструменты, как:
Пример пользовательской истории: менеджер по логистике персонала хочет построить оптимальные маршруты перевозок сотрудников от мест жительства к рабочим площадкам предприятия, чтобы минимизировать финансовые и временные затраты на транспортировку.
Кроме того, для погружения в предметную область, первичной генерации вопросов на интервью, а также построения BPMN и UML-моделей аналитикам рекомендуется использовать общедоступные инструменты на базе искусственного интеллекта. Для работы с чувствительной информацией в IBS развернута локальная лингвистическая модель.
Одним из главных принципов при выявлении требований является проактивность. Аналитику важно не просто «конспектировать» пожелания представителей бизнеса в виде функциональных и нефункциональных требований к информационной системе, а на основании опыта декомпозировать их и предлагать наиболее полное и эффективное решение.
Конечно, невозможно обладать полной экспертизой во всех отраслях, для которых приходится разрабатывать программное обеспечение, поэтому важно в проектную команду включать экспертов-предметников бизнеса. Задача аналитика при взаимодействии с таким экспертом заключается в том, чтобы помочь более полно сформулировать требования к будущей системе, образ результата.
Например, исходное требование бизнеса сформулировано как «сократить затраты на перевозку сотрудников от мест жительства до рабочих площадок предприятия». Сформированный список требований по итогам анализа может выглядеть так:
Должны быть возможности:
Особое внимание уделяется моделированию бизнес-процессов. Сначала строится модель AS IS, описывающая текущие бизнес-процессы организации/предприятия, затем проводится ее анализ на предмет возможной оптимизации и предлагается целевая модель TO BE. В качестве основного подхода по оптимизации бизнес-процессов выбрана концепция LEAN, или бережливое производство.
Например, в процессе AS IS эксперты согласовывают планы мероприятий поэтапно, причем часть проверок выполняется последовательно. Это приводит к задержкам, поскольку план не может двигаться дальше или на доработку, пока все эксперты не завершат проверку.
В версии TO BE план разделен на пакеты по направлениям, и каждый пакет согласуется независимо экспертами по соответствующим направлениям. Это дало следующие преимущества:
Соблюдение принципа проактивности в выявлении требований, вовлечение экспертов в процесс и применение подходов оптимизации бизнес-процессов служат основой для реализации эффективных информационных систем и позволяют обеспечить их соответствие реальным потребностям бизнеса.
Создание эффективной архитектуры данных и проектирование ее наполнения, в том числе через интеграцию с внешними и смежными системами, требуют не только технической экспертизы, но и глубокого понимания бизнес-контекста. Успешное решение этой задачи строится на следующих основных принципах:
Такой подход позволяет разрабатывать системы, которые соответствуют текущим требованиям и адаптируются к будущим изменениям, обеспечивая надежность, безопасность и масштабируемость.
Подходы и технические решения, касающиеся архитектуры данных и реализации интеграции, давно известны и многократно описаны. Основная сложность на этом этапе заключается в том, чтобы учесть все необходимые данные, их источники и согласовать форматы взаимодействия со смежными системами. Эти задачи лежат не столько в технологической, сколько в организационной плоскости.
Часто в проектах бывает так, что параллельно разработке информационной системы выполняется модернизация (а бывает и создание) системы-источника. Крайне важно как можно раньше согласовать формат и состав данных, которыми будут обмениваться информационные системы. Порой это сложно, поскольку требования к смежной системе, а вместе с ними и состав данных, могут меняться в ходе реализации. Этот риск отчасти можно минимизировать путем проектирования отдельного слоя API с поддержкой версионирования и слоя хранения данных, использующихся для интеграции.
При проектировании архитектуры хранения данных также важно оценить их текущий объем и перспективу прироста в течение ближайшего года, пяти и десяти лет, а по результатам оценки принять решения по выбору подходов к хранению, агрегации, логированию изменений, созданию резервных копий и т. д.
Проектирование архитектуры данных и интеграции — это баланс между техническими решениями и организационной согласованностью. Вклад в масштабируемость, безопасность и документацию решения окупается снижением рисков при эксплуатации и повышением гибкости бизнеса.
Наиболее важной задачей системного архитектора при разработке программной и технической архитектуры информационной системы является обеспечение оптимального соотношения между функциональными требованиями, производительностью, масштабируемостью, безопасностью, стоимостью и возможностью развития будущей системы.
На этапе проектирования системный архитектор определяет основные компоненты системы и их взаимодействие, выбирает архитектурные паттерны (например, MVC, микросервисы, слоистая архитектура) и принципы проектирования (допустим, разделение ответственности, модульность), подходящие технологии, языки программирования, фреймворки и системы управления базами данных, продумывает методы и средства защиты данных и компонентов от угроз информационной безопасности.
Результатом этапа становится набор архитектурных моделей системы, которые представляются в виде диаграмм и схем (например, С4, сетевая диаграмма).
Качественная архитектура, с одной стороны, является результатом применения набора шаблонов и подходов, а с другой — опыта и знаний самого системного архитектора. Поэтому на этапе выявления и анализа требований архитектору важно знать цель создания системы, погрузиться в ожидания бизнес-заказчика, понять возможные перспективы развития системы в будущем и учесть технические требования и ограничения.
После формирования и описания архитектуры системы важно проконтролировать ее соответствие критериям качества. Некоторые из таких критериев:
Архитектура информационной системы должна быть сбалансированной — учитывать функциональные и нефункциональные требования, ограничения и перспективы развития системы в будущем.
Хорошо продуманная архитектура через обеспечение адаптивности к изменениям и масштабируемость позволит сделать разрабатываемую информационную систему одним из факторов конкурентоспособности бизнеса.
Если вы планируете автоматизировать уникальные бизнес-процессы или создать индивидуальное программное решение, обратитесь за консультацией к экспертам IBS. Мы окажем поддержку в уточнении требований, поможем разобраться в деталях и предложим оптимальные варианты.