Функциональная архитектура в проектах внедрения на платформе 1С
Уже почти десять лет принимаю участие в проектах внедрения на платформе 1С в роли функционального архитектора. Специализация функционального архитектора появилась относительно недавно, вследствие роста сложности информационных систем, а список активностей по управлению функциональной архитектурой может быть разным и зависит от частного представления о процессах разработки и внедрения в конкретной компании.
В статье не буду погружаться в теории по вопросам функциональной архитектуры, а изложу свое видение основных активностей и проблем, и подходы к их решению, сложившиеся в моей практике.
Одно из определений функциональной архитектуры: функциональная архитектура — это детальное описание и структура функциональности создаваемой системы, спроектированные с учётом технологических, пользовательских и бизнес-требований, а также иерархии функций, их зависимости друг от друга и использования в компонентах такой системы.
Цели функциональной архитектуры:
Снижение рисков от некорректного результата, реализации не требуемой функциональности
Управляемость разработки и внедрения
Целостное описание и представление для всех участников разрабатываемой системы.
На практике можно выделить основные артефакты функциональной архитектуры:
Требования, на основании которых формируется набор функций приложения
при внедрении бизнес-приложений также проводится анализ бизнес-процессов, позволяющий выявить сценарии и требования пользователей по использованию приложений, а также бизнес-сущности для автоматизации в информационной системе
Компоненты — сами приложения, модули приложений — относительно независимые, заменяемые единицы, выполняющие одну или несколько функций
Функции — обособленные элементы поведения компонентов, реализующие сценарии использования компонента
Модель данных — объекты данных, отражающие бизнес-сущности в информационной системе и их взаимосвязи
Интеграционные потоки — элементы, отражающие передачу информации (один или несколько объектов данных) между компонентами приложений.
Также с артефактами архитектуры связаны задачи проекта, реализующие последовательность и активности по переходу от существующего к целевому состоянию, а также документация, формирующая базу знаний об архитектуре.
Важно понимать, что требования являются элементами управления архитектурой (инструмент управления архитектора), в то время как задачи — элементами управления проектом (инструмент управления руководителя проекта). Например, требование по реализации некоторого инструмента обработки данных может быть выделено, в три задачи: анализ требования, разработка функционала, тестирование. Однако, требования являются основанием иерархической структуры работ и формируют структуру и последовательность исполнения проекта.
Управление функциональной архитектурой включает активности:
Выявление и анализ бизнес-целей и задач, пользовательских требований — для чего нужна внедряемая система и как пользователи хотят ее использовать (пользовательские сценарии)
Управление требованиями (управление жизненным циклом требований, управление прослеживаемостью, приоритизация)
Описание существующей архитектуры, управление состоянием архитектуры и процессами изменений
Моделирование, проектирование целевой архитектуры — на основании требований пользователя и прочих факторов (сопровождение, разработка, внедрение и др.), определение компонентов и функций архитектуры, распределение функций и объектов по компонентам, верхнеуровневое определение интеграционных потоков
Формирование функциональных требований — что нужно сделать для настройки и доработки/разработки компонентов информационной системы
Формирование иерархической структуры работ перехода от существующего состояния к целевому
Формирование базы знаний и документации о функциональной архитектуре.
Основные проблемы в управлении функциональной архитектурой:
Сложность поддержания в актуальном состоянии графических моделей — в сложных системах с большим количеством элементов формирование целостных графических моделей проблематично, а регистрация изменений в некоторых случаях становится невозможной
Иерархичность требований и элементов архитектуры — требования не статичны; в начале проекта требования к системе верхнеуровневые; в ходе проекта требования декомпозируются и детализируются, изменяются, делятся; без использования средств автоматизации (например, учет требований и артефактов архитектуры в Excel) проблематично поддерживать реестр требований в актуальном состоянии
Прослеживаемость артефактов анализа (требований, документации, задач проекта и элементов архитектуры)
без использования средств автоматизации в сложных системах реализовать адекватную прослеживаемость невозможно
на текущий момент существует множество программных продуктов для управления требованиями, управления проектами, описания архитектуры, управления знаниями и документацией; однако отсутствуют единый инструмент, позволяющий связать все артефакты между собой и реализовать прослеживаемость между видами требований, между требованиями и элементами архитектуры, между артефактами анализа, документацией и задачами проекта
Дополнительные трудозатраты по управлению функциональной архитектурой, не очевидные Заказчику.
Большая часть описанных проблем связана с поддержанием функциональной архитектуры в актуальном состоянии. В интернете широко распространен мем (в различных вариациях): «Не так страшны первые 90% как вторые». Он именно об этом. Состав проекта не статичен, он постоянно меняется, поэтому актуальное состояние требований и функциональной архитектуры позволяет сделать изменения более осознанными и управляемыми.
Для решения этих проблем на платформе 1С разработана конфигурация «Функциональный архитектор», в которой реализованы инструменты для учета выше выделенных артефактов, реализации прослеживаемости и представления артефактов архитектуры в виде диаграмм.
Для отражения в архитектуре всех участвующих артефактов в конфигурации реализована следующая модель данных:
Выделены два базовых справочника:
Архитектуры — определяют Enterprise-архитектуру внедрения
Проекты — объединяют проектные активности по изменению архитектур, требования и документацию.
Все прочие справочники, отражающие артефакты архитектуры и проектов подчинены одному из базовых, которые не зависят друг от друга.
В границах архитектур реализованы подчиненные справочники:
Интеграционные потоки, отражающие информационные потоки между системами
Бизнес-информационные системы — техническая сущность для разграничения доступа к артефактам архитектуры
Объекты системы — артефакты архитектуры (функции, процессы, бизнес-сущности, объекты данных и др.);
Варианты архитектуры — отражают ключевые состояния архитектуры в процессе ее изменения (например, существующая архитектура, целевая архитектура); интеграционные потоки и объекты систем могут входить в один или несколько вариантов архитектур.
В границах проектов реализованы подчиненные справочники:
Версии проектов — отражают версию структуры работ проекта внедрения, например, предпроектное обследование, фактическое исполнение проекта, прогноз изменения проекта; версии можно создавать на основании других версий и сравнивать между собой; версии включают справочники:
Стадии проекта — группировка работ по промежуточным результатам, имеющим ценность в проекте
Задачи проектов — собственно работы, выполняемые в проекте
Требования — справочник, в котором хранятся различные виды требований
Документы — справочник документации к проекту.
В системе реализована прослеживаемость между:
требованиями и другими требованиями
требованиями и объектами систем
задачами, требованиями и объектами систем
документами и прочими артефактами системы (задачи, требования, объекты систем).
В основу типизации связей и объектов систем заложены принципы языка моделирования Archimate. В справочнике типов связей и объектов созданы предопределенные элементы, соответствующие типам связей и объектов нотации.
Справочник требований иерархический. В справочнике фиксируются все виды требований: бизнес-цели и задачи, пользовательские и функциональные требования. Требования могут декомпозироваться на неограниченное количество уровней как при проектировании так и в процессе проекта. Для управления жизненным циклом требований реализована система статусов требований. Статусы требований периодические. Автоматизирована прослеживаемость связей с другими требованиями, объектами систем, задачами и документами.
В справочнике объектов систем фиксируются бизнес-процессы и их составляющие, элементы архитектуры (компоненты, функции приложения, объекты данных и пр.) информационных систем. Как и справочник требований, справочник объектов систем иерархический. Для него реализованы управление статусами объектов и прослеживаемость с другими объектами и интеграционными потоками, задачами, требованиями и документами.
Реализован подчиненный версиям проектами и стадиям справочник задач проекта.
Помимо учета, в задачах реализована возможность:
Автоматизировано формировать связи между требованиями и объектами
Регистрировать плановые и фактические трудозатраты по задачам, распределять трудозатраты между требованиями и объектами, привязанными к задачам
Фиксировать изменения в элементах архитектуры, связанными с задачами
Актуализировать состояние требований и объектов системы.
Функция оценки трудозатрат не относится напрямую к функциональной архитектуре, однако позволяет спланировать трудозатраты по проекту на основании функциональных требований или получить статистику трудозатрат по уже выполненным проектам, в т.ч. в разрезе требований и артефактов архитектуры.
Использование интеграции с системами управления проектами, помимо сокращения трудозатрат на создание задач вручную, позволяет автоматизировать контроль изменений в проекте.
Если представить основные активности проекте следующим образом
Можно выделить две точки контроля функционального архитектора за изменениями в проекта:
КТ1 — по завершении детального анализа возникают новые или детализируются требования в проекте — функциональный архитектор в этой точке должен актуализировать требования к системе
КТ2 — по завершении реализации требования также появляются дополнительные требования, и, кроме того, появляется задача актуализировать архитектуру и откорректировать план работ.
Так же в этих точках контролируется качество анализа и реализации требований.
В решении реализован инструмент обмена с системами управления проектами. Инструмент в процессе загрузки позволяет выделить новые или изменившие статус задачи проекта и актуализировать состояние требований и объектов систем. На текущий момент реализованы интеграция с системой OpenProject и выгрузка/загрузка задач в Excel.
Таким образом, решение позволяет оперативно отслеживать и актуализировать состояния требований и объектов систем, что снижает риск не качественного отражения в функциональной архитектуре изменений в проекте.
Без использования графических моделей управление функциональной архитектурой трудно представить. Однако:
Трудозатратно, а иногда не возможно поддержание целостных моделей сложных систем
Платформа 1С не поддерживает диаграммы достаточным образом
Часто различные нотации применяются для отражения разных элементов архитектуры.
В конфигурации принято решение отказаться от реализации редактора диаграмм внутри системы. Реализован импорт диаграмм из внешних систем (на текущий момент поддерживаются форматы draw.io и archimate). Такой подход позволяет использовать разные нотации для разных элементов архитектуры, а также связать один и тот же объект системы с различными элементами нескольких схем.
Например, в системе загружена карта процессов в произвольной нотации:
Загружаемые схемы интерактивные — двойным щелчком можно открыть карточку объекта системы, найти его в списке объектов или перейти в подчиненную схему (если к выбранному объекту так же привязана схема):
Загружаются как сами объекты систем, так и связи между ними. Реализована пользовательская настройка соответствия типов объектов и связей с атрибутами элементов загружаемых схем, что позволяет автоматически определять тип объекта или связи, а в формате archimate реализовать сквозную идентификацию объекта для нескольких схем.
По загруженным артефактам и связям между ними формируется отчетность. Например, для загруженной схемы процесса может быть автоматически сгенерирована табличная форма процесса.
Кроме объектов систем из схем автоматически загружаются данные об информационных потоках:
Таким образом в программном решении:
Автоматизирован учет требований и артефактов архитектуры с использованием иерархических структур и возможностью декомпозиции, добавления и изменения; автоматизировано управление жизненным циклом требований и артефактов архитектуры
Реализована прослеживаемость между требованиями и артефактами архитектуры
Посредством импорта из редакторов диаграмм автоматизировано графическое представление артефактов архитектуры в различных нотациях, связь артефактов архитектуры с элементами схем .
Кроме того:
Автоматизирован процесс формирования иерархической структуры работ, оценки планируемых трудозатрат, формирование дорожной карты, в т.ч. с представлением стадий в виде диаграммы Ганта
Автоматизирован импорт из систем управления проектами задач и фактических трудозатрат
Автоматизирован учет документации проекта — реестр документации хранится в системе, а сами документы могут находится на диске, в системе управления знаниями в облаке или прикреплены к карточке документа непосредственно в системе
Автоматизирована подготовка отчетности — реестры требований, объектов, документов; отчетность по связям между объектами.
Примечание: разработанное решение не является системой управления проектами, системой управления разработкой (например, как СППР) или системой управления документацией. Однако, при отсутствии таковых, система может быть в упрощенном виде использована для выполнения таких функций.
Видеоролик презентации функций решения на сквозном примере можно посмотреть здесь: https://rutube.ru/video/e0d426c62a6bc8972b25c37980a28bf3/
