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

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

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

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

• Снижение рисков от некорректного результата, реализации не требуемой функциональности

• Управляемость разработки и внедрения

• Целостное описание и представление для всех участников разрабатываемой системы.

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

• Требования, на основании которых формируется набор функций приложения

  • при внедрении бизнес-приложений также проводится анализ бизнес-процессов, позволяющий выявить сценарии и требования пользователей по использованию приложений, а также бизнес-сущности для автоматизации в информационной системе

• Компоненты – сами приложения, модули приложений - относительно независимые, заменяемые единицы, выполняющие одну или несколько функций

• Функции – обособленные элементы поведения компонентов, реализующие сценарии использования компонента

• Модель данных - объекты данных, отражающие бизнес-сущности в информационной системе и их взаимосвязи

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

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

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

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

• Выявление и анализ бизнес-целей и задач, пользовательских требований – для чего нужна внедряемая система и как пользователи хотят ее использовать (пользовательские сценарии)

• Управление требованиями (управление жизненным циклом требований, управление прослеживаемостью, приоритизация)

• Описание существующей архитектуры, управление состоянием архитектуры и процессами изменений

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

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

• Формирование иерархической структуры работ перехода от существующего состояния к целевому

• Формирование базы знаний и документации о функциональной архитектуре.

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

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

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

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

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

  • без использования средств автоматизации в сложных системах реализовать адекватную прослеживаемость невозможно

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

• Дополнительные трудозатраты по управлению функциональной архитектурой, не очевидные Заказчику.

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

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

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

• Архитектуры – определяют Enterprise-архитектуру внедрения

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

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

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

• Интеграционные потоки, отражающие информационные потоки между системами

• Бизнес-информационные системы – техническая сущность для разграничения доступа к артефактам архитектуры

  • Объекты системы – артефакты архитектуры (функции, процессы, бизнес-сущности, объекты данных и др.);

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

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

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

  • Стадии проекта – группировка работ по промежуточным результатам, имеющим ценность в проекте

  • Задачи проектов – собственно работы, выполняемые в проекте

• Требования – справочник, в котором хранятся различные виды требований

• Документы – справочник документации к проекту.

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

• требованиями и другими требованиями

• требованиями и объектами систем

• задачами, требованиями и объектами систем

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

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

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

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

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

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

• Автоматизировано формировать связи между требованиями и объектами

• Регистрировать плановые и фактические трудозатраты по задачам, распределять трудозатраты между требованиями и объектами, привязанными к задачам

• Фиксировать изменения в элементах архитектуры, связанными с задачами

• Актуализировать состояние требований и объектов системы.

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

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

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

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

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

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

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

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

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

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

• Трудозатратно, а иногда не возможно поддержание целостных моделей сложных систем

• Платформа 1С не поддерживает диаграммы достаточным образом

• Часто различные нотации применяются для отражения разных элементов архитектуры.

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

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

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

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

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

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

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

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

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

• Реализована прослеживаемость между требованиями и артефактами архитектуры

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

Кроме того:

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

• Автоматизирован импорт из систем управления проектами задач и фактических трудозатрат

• Автоматизирован учет документации проекта – реестр документации хранится в системе, а сами документы могут находится на диске, в системе управления знаниями в облаке или прикреплены к карточке документа непосредственно в системе

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

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

Видеоролик презентации функций решения на сквозном примере можно посмотреть здесь: https://rutube.ru/video/e0d426c62a6bc8972b25c37980a28bf3/