Функциональная архитектура в проектах внедрения на платформе 1С

Kate · 2 Июн 2024

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

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

Одно из определений функциональной архитектуры: функциональная архитектура - это детальное описание и структура функциональности создаваемой системы, спроектированные с учётом технологических, пользовательских и бизнес-требований, а также иерархии функций, их зависимости друг от друга и использования в компонентах такой системы.

Цели функциональной архитектуры:

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

На практике можно выделить основные артефакты функциональной архитектуры:

Требования, на основании которых формируется набор функций приложения
- при внедрении бизнес-приложений также проводится анализ бизнес-процессов, позволяющий выявить сценарии и требования пользователей по использованию приложений, а также бизнес-сущности для автоматизации в информационной системе
Компоненты – сами приложения, модули приложений - относительно независимые, заменяемые единицы, выполняющие одну или несколько функций
Функции – обособленные элементы поведения компонентов, реализующие сценарии использования компонента
Модель данных - объекты данных, отражающие бизнес-сущности в информационной системе и их взаимосвязи
Интеграционные потоки – элементы, отражающие передачу информации (один или несколько объектов данных) между компонентами приложений.

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

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

Управление функциональной архитектурой включает активности:

Выявление и анализ бизнес-целей и задач, пользовательских требований – для чего нужна внедряемая система и как пользователи хотят ее использовать (пользовательские сценарии)
Управление требованиями (управление жизненным циклом требований, управление прослеживаемостью, приоритизация)
Описание существующей архитектуры, управление состоянием архитектуры и процессами изменений
Моделирование, проектирование целевой архитектуры – на основании требований пользователя и прочих факторов (сопровождение, разработка, внедрение и др.), определение компонентов и функций архитектуры, распределение функций и объектов по компонентам, верхнеуровневое определение интеграционных потоков
Формирование функциональных требований – что нужно сделать для настройки и доработки/разработки компонентов информационной системы
Формирование иерархической структуры работ перехода от существующего состояния к целевому
Формирование базы знаний и документации о функциональной архитектуре.

Большая часть проблем управления функциональной архитектурой связана с ее поддержанием в актуальном состоянии. В интернете широко распространен мем (в различных вариациях): «Не так страшны первые 90% проекта как вторые». Он именно об этом. Состав проекта не статичен, он постоянно меняется, поэтому актуальное состояние требований и функциональной архитектуры позволяет сделать изменения более осознанными и управляемыми.

Основные проблемы актуализации функциональной архитектуры:

Сложность поддержания в актуальном состоянии графических моделей – в сложных системах с большим количеством элементов формирование целостных графических моделей проблематично, а регистрация изменений в некоторых случаях становится невозможной
Иерархичность требований и элементов архитектуры – требования не статичны; в начале проекта требования к системе верхнеуровневые; в ходе проекта требования декомпозируются и детализируются, изменяются, делятся; без использования средств автоматизации (например, учет требований и артефактов архитектуры в Excel) проблематично поддерживать реестр требований в актуальном состоянии
Прослеживаемость артефактов анализа (требований, документации, задач проекта и элементов архитектуры)
- без использования средств автоматизации в сложных системах реализовать адекватную прослеживаемость невозможно
- на текущий момент существует множество программных продуктов для управления требованиями, управления проектами, описания архитектуры, управления знаниями и документацией; однако отсутствуют единый инструмент, позволяющий связать все артефакты между собой и реализовать прослеживаемость между видами требований, между требованиями и элементами архитектуры, между артефактами анализа, документацией и задачами проекта
Дополнительные трудозатраты по управлению функциональной архитектурой, не очевидные Заказчику.

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

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

Выделены два базовых справочника:

Архитектуры – определяют Enterprise-архитектуру внедрения
Проекты – объединяют проектные активности по изменению архитектур, требования и документацию.

Все прочие справочники, отражающие артефакты архитектуры и проектов подчинены одному из базовых, которые не зависят друг от друга.

В границах архитектур реализованы подчиненные справочники:

Интеграционные потоки, отражающие информационные потоки между системами
Бизнес-информационные системы – техническая сущность для разграничения доступа к артефактам архитектуры
- Объекты системы – артефакты архитектуры (функции, процессы, бизнес-сущности, объекты данных и др.);
Варианты архитектуры – отражают ключевые состояния архитектуры в процессе ее изменения (например, существующая архитектура, целевая архитектура); интеграционные потоки и объекты систем могут входить в один или несколько вариантов архитектур.

В границах проектов реализованы подчиненные справочники:

Версии проектов – отражают версию структуры работ проекта внедрения, например, предпроектное обследование, фактическое исполнение проекта, прогноз изменения проекта; версии можно создавать на основании других версий и сравнивать между собой; версии включают справочники:
- Стадии проекта – группировка работ по промежуточным результатам, имеющим ценность в проекте
- Задачи проектов – собственно работы, выполняемые в проекте
Требования – справочник, в котором хранятся различные виды требований
Документы – справочник документации к проекту.

В системе реализована прослеживаемость между:

требованиями и другими требованиями
требованиями и объектами систем
задачами, требованиями и объектами систем
документами и прочими артефактами системы (задачи, требования, объекты систем).

В основу типизации связей и объектов систем заложены принципы языка моделирования Archimate. В справочнике типов связей и объектов созданы предопределенные элементы, соответствующие типам связей и объектов нотации.

Справочник требований иерархический. В справочнике фиксируются все виды требований: бизнес-цели и задачи, пользовательские и функциональные требования. Требования могут декомпозироваться на неограниченное количество уровней как при проектировании так и в процессе проекта. Для управления жизненным циклом требований реализована система статусов требований. Статусы требований периодические. Автоматизирована прослеживаемость связей с другими требованиями, объектами систем, задачами и документами.

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

Реализован подчиненный версиям проектами и стадиям справочник задач проекта.

Помимо учета, в задачах реализована возможность:

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

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

Использование интеграции с системами управления проектами, помимо сокращения трудозатрат на создание задач вручную, позволяет автоматизировать контроль изменений в проекте.

Если представить основные активности проекте следующим образом

Можно выделить две точки контроля функционального архитектора за изменениями в проекта:

КТ1 – по завершении детального анализа возникают новые или детализируются требования в проекте - функциональный архитектор в этой точке должен актуализировать требования к системе
КТ2 – по завершении реализации требования также появляются дополнительные требования, и, кроме того, появляется задача актуализировать архитектуру и откорректировать план работ.

Так же в этих точках контролируется качество анализа и реализации требований.

В решении реализован инструмент обмена с системами управления проектами. Инструмент в процессе загрузки позволяет выделить новые или изменившие статус задачи проекта и актуализировать состояние требований и объектов систем. На текущий момент реализованы интеграция с системой OpenProject и выгрузка/загрузка задач в Excel.

Таким образом, решение позволяет оперативно отслеживать и актуализировать состояния требований и объектов систем, что снижает риск не качественного отражения в функциональной архитектуре изменений в проекте.

Без использования графических моделей управление функциональной архитектурой трудно представить. Однако:

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

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

Например, в системе загружена карта процессов в произвольной нотации:

Загружаемые схемы интерактивные – двойным щелчком можно открыть карточку объекта системы, найти его в списке объектов или перейти в подчиненную схему (если к выбранному объекту так же привязана схема):

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

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

Кроме объектов систем из схем автоматически загружаются данные об информационных потоках:

Таким образом в программном решении:

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

Кроме того:

Автоматизирован процесс формирования иерархической структуры работ, оценки планируемых трудозатрат, формирование дорожной карты, в т.ч. с представлением стадий в виде диаграммы Ганта
Автоматизирован импорт из систем управления проектами задач и фактических трудозатрат
Автоматизирован учет документации проекта – реестр документации хранится в системе, а сами документы могут находится на диске, в системе управления знаниями в облаке или прикреплены к карточке документа непосредственно в системе
Автоматизирована подготовка отчетности – реестры требований, объектов, документов; отчетность по связям между объектами.

Примечание: разработанное решение не является системой управления проектами, системой управления разработкой (например, как СППР) или системой управления документацией. Однако, при отсутствии таковых, система может быть в упрощенном виде использована для выполнения таких функций.