При анализе информационных систем бизнес-аналитику недостаточно понимать, какие функции выполняет программное решение. Не менее важно установить, откуда поступают данные, где они преобразуются, куда передаются, где сохраняются и какие внешние участники обмениваются ими с системой. Без такого представления требования легко превращаются в набор разрозненных функций, между которыми остаются неявными информационные зависимости.
Для решения этой задачи BABOK предлагает технику «Диаграммы потоков данных» (Data Flow Diagrams, DFD). Ее предметом является не последовательность действий как таковая, а движение и преобразование данных. Именно поэтому DFD занимает особое место между процессным, функциональным и информационным моделированием: эта техника позволяет рассматривать деятельность через то, какая информация поступает на вход, как она изменяется и какой результат передается дальше.
Диаграммы потоков данных особенно полезны при анализе транзакционных систем, определении границ решения, исследовании интеграций и проверке функциональной декомпозиции. При этом BABOK подчеркивает важное ограничение: DFD не показывает последовательность действий. Поэтому ее следует воспринимать не как замену процессной модели, а как отдельный аналитический инструмент.
Назначение техники
Согласно BABOK, диаграммы потоков данных показывают, откуда поступают данные, какие виды деятельности их обрабатывают и что происходит с результатом обработки: сохраняется ли он либо используется другой деятельностью или внешней сущностью.
Это назначение можно сформулировать как ответ на четыре базовых вопроса: кто предоставляет информацию, что с ней происходит, где она хранится и кому передается результат.
Такой взгляд особенно важен при анализе систем, состоящих из множества приложений, интеграций и хранилищ. Функция сама по себе может выглядеть понятной, но ее реализация зависит от источника входных данных и получателя результата. DFD делает эти зависимости явными.
Описание техники
BABOK определяет диаграммы потоков данных как средство отображения преобразования данных. Они используются для представления транзакционных систем и для иллюстрации границ физической, логической или ручной системы.
Диаграмма показывает движение и преобразование данных между внешними сущностями и процессами. Выход одного процесса или внешней сущности становится входом для другого процесса. Одновременно модель может отображать временные и постоянные хранилища данных.
Сами данные, присутствующие на диаграмме, должны быть определены дополнительно, например с помощью техники «Словарь данных». Таким образом, DFD отвечает прежде всего на вопрос о движении информации, тогда как словарь данных раскрывает ее состав и смысл.
DFD может строиться на нескольких уровнях абстракции. Самый высокий уровень представляет собой контекстную диаграмму. На ней вся анализируемая система рассматривается как единый механизм преобразования данных, а вокруг располагаются внешние сущности, являющиеся источниками или потребителями информации.
Следующий уровень — диаграмма уровня 1. На ней единая система раскрывается как набор процессов с соответствующими входами, выходами и хранилищами. Последующие уровни — 2, 3 и далее — позволяют декомпозировать отдельные процессы предыдущего уровня. Благодаря этому бизнес-аналитик может постепенно переходить от общего понимания системы к необходимой степени детализации.
BABOK также разделяет логические и физические диаграммы потоков данных. Логическая DFD показывает будущее или принципиальное состояние: какие преобразования должны происходить независимо от физических ограничений реализации. Физическая DFD включает конкретные проявления данных и механизмов их обработки: хранилища, формы, устройства и другие физические компоненты. Она может описывать как текущее решение, так и его будущую реализацию.
Элементы техники
BABOK определяет четыре элемента диаграммы потоков данных: внешние сущности, хранилища данных, процессы и потоки данных. Именно их сочетание формирует модель.
Внешняя сущность
Внешняя сущность — человек, организация, автоматизированная система или устройство, способное производить или получать данные. Принципиальным является слово «внешняя»: такая сущность находится за границами анализируемой системы.
Внешняя сущность является источником либо получателем информации, а иногда одновременно выполняет обе роли. Поэтому у нее должен существовать как минимум один входящий или исходящий поток данных.
BABOK рекомендует обозначать внешние сущности существительными. На диаграммах они обычно изображаются прямоугольниками и присутствуют как на контекстном, так и на более низких уровнях.
Для бизнес-аналитика внешние сущности особенно важны при определении скоупа. Если организация моделирует CRM, внешними сущностями могут быть клиент, платежный сервис или государственная информационная система. При этом какой-нибудь внутренний модуль самой CRM внешней сущностью относительно всей CRM не является.
Хранилище данных
Хранилище данных представляет собой банк информации, которая сохраняется для дальнейшего использования и может многократно считываться. BABOK характеризует его как данные в состоянии покоя.
У каждого хранилища должен быть хотя бы один входящий или исходящий поток. Если данные в хранилище поступают, но никогда не используются, либо читаются из него без понятного источника появления, модель указывает на этот пробел, требующий дополнительного анализа.
Хранилище не обязательно следует сразу трактовать как конкретную таблицу базы данных. Особенно на логическом уровне оно отражает сам факт необходимости сохранения информации. Физическая реализация этого хранения определяется отдельно.
Процесс
Процесс в DFD представляет ручную или автоматизированную деятельность, выполняемую в интересах бизнеса и преобразующую входные данные в выходную информацию.
Согласно BABOK, название процесса должно включать глагол и существительное. Такая формулировка подчеркивает совершаемое преобразование: например, «Проверить заявку», «Рассчитать стоимость», «Зарегистрировать документ».
Каждый процесс должен иметь как минимум один входящий и один исходящий поток данных. Это важное правило обладает практической диагностической ценностью. Процесс без входа формирует результат неизвестного происхождения, а процесс без выхода не демонстрирует результата своего выполнения.
При этом процесс на DFD не следует приравнивать к полноценному бизнес-процессу. BABOK прямо указывает, что преобразования данных мало говорят о процессе или заинтересованной стороне. Здесь процесс является прежде всего преобразователем информации.
Поток данных
Поток данных показывает перемещение информации между внешними сущностями, процессами и хранилищами. Именно потоки объединяют отдельные элементы в единую модель.
Каждый поток входит в процесс или выходит из него, демонстрируя его информационные входы и выходы. На диаграмме поток представляется направленной линией со стрелкой и именуется существительным.
Название потока должно отражать передаваемую информацию, а не действие. Например, корректными названиями будут «Данные клиента», «Заявка», «Результат проверки» или «Сведения о платеже».
Через анализ потоков бизнес-аналитик может увидеть, каким участникам и компонентам требуется конкретная информация, где она создается и какие преобразования проходит до достижения получателя.
Практическое применение
Работа с DFD обычно начинается с определения границы анализируемой системы. На контекстной диаграмме бизнес-аналитик представляет систему как единый процесс и определяет внешние сущности, которые передают ей данные или получают результаты.
После согласования контекста модель декомпозируется. На уровне 1 определяются основные процессы обработки информации, используемые ими хранилища и потоки между элементами. Если отдельный процесс остается слишком сложным, он раскрывается на следующем уровне.
В работе могут участвовать бизнес-аналитики, специалисты предметной области, архитекторы, системные аналитики, разработчики и представители интегрируемых систем. Состав участников зависит от конкретной задачи: бизнес-пользователи помогают подтвердить смысл информации и преобразований, а технические специалисты — физические источники, хранилища и интерфейсы.
Результатом становится набор согласованных диаграмм различного уровня детализации. Дополнительно бизнес-аналитик может сформировать словарь данных, спецификации интерфейсов и требования к преобразованиям информации.
На основании DFD уточняются границы системы, перечень интеграций, необходимые хранилища, информационные зависимости функций и содержание интерфейсов.
Практический пример
Предположим, что организация внедряет систему электронного согласования договоров. Сейчас сотрудники пересылают документы по электронной почте, сведения о контрагентах хранятся в ERP, а итоговые документы вручную помещаются в архив.
На первом этапе бизнес-аналитик строит контекстную DFD. В центре находится система согласования договоров. Внешними сущностями выступают инициатор договора, ERP, участник согласования и электронный архив.
От инициатора в систему поступают «Данные договора». Из ERP передаются «Данные контрагента». Участнику согласования система предоставляет «Договор на согласование», а обратно получает «Результат согласования». После завершения обработки в архив передается «Утвержденный договор».
Уже контекстный уровень позволяет определить основные границы решения и внешние интерфейсы.
Затем бизнес-аналитик строит диаграмму уровня 1. Единый процесс декомпозируется, например, на «Зарегистрировать договор», «Получить данные контрагента», «Провести согласование» и «Передать договор в архив». Добавляются хранилища «Договоры» и «История согласования».
Теперь становится видно, что результат регистрации используется процессом согласования, сведения о ходе согласования сохраняются отдельно, а архив получает документ только после формирования итогового результата.
При анализе обнаруживается пробел: процесс «Провести согласование» использует данные о маршруте согласования, но источник этих данных на диаграмме отсутствует. Это означает, что требуется дополнительное исследование. В результате выявляется необходимость хранения правил маршрутизации, и на DFD появляется соответствующее хранилище.
Другой вопрос возникает с данными контрагента. Если они каждый раз запрашиваются из ERP, это один вариант модели. Если система согласования должна сохранять их локальную копию, появляется дополнительное хранилище и требования к его обновлению.
После согласования логической модели бизнес-аналитик может построить физическую DFD будущего решения. На ней логические процессы связываются с конкретными приложениями, интеграционными механизмами и физическими хранилищами.
В итоге DFD помогает не только описать движение информации, но и обнаружить отсутствующие источники данных, скрытые зависимости между функциями и дополнительные интеграционные требования.
Хорошие и плохие практики
Хорошая практика — начинать с контекстной диаграммы и постепенно выполнять декомпозицию. Такой подход позволяет сначала согласовать границы системы и только после этого переходить к внутренней структуре. Попытка сразу построить максимально подробную DFD часто приводит к большой и плохо читаемой модели.
Не менее важно сохранять смысловую согласованность между уровнями. Если на верхнем уровне система получает определенный набор данных от внешней сущности, декомпозиция не должна без объяснения создавать совершенно новые внешние взаимодействия.
Полезно также различать логическую и физическую модель. Если на одной диаграмме смешиваются бизнес-преобразования, конкретные таблицы, приложения, устройства и технические детали, становится трудно понять, что является необходимостью бизнеса, а что — выбранной реализацией.
Плохой практикой является использование потоков без содержательных названий: «данные», «информация», «запрос». Формально стрелка существует, но аналитической ценности в таком случае почти не дает. Название должно позволять понять, что именно перемещается между элементами.
Типичные ошибки
Одна из наиболее распространенных ошибок — использование DFD как блок-схемы процесса. Бизнес-аналитик пытается расположить процессы в хронологическом порядке и воспринимает стрелки как переход управления. Однако DFD показывает движение данных, а не последовательность выполнения действий. В результате модель начинает отвечать на вопрос, для которого эта техника не предназначена.
Вторая ошибка — отсутствие преобразования. Если процесс получает и возвращает совершенно одинаковую информацию, следует проверить, действительно ли здесь существует самостоятельный процесс обработки данных.
Третья проблема — чрезмерная детализация. BABOK отмечает, что DFD крупномасштабных систем может стать сложной и трудной для понимания. Поэтому декомпозиция должна распределять сложность между уровнями, а не превращать одну диаграмму в карту всей информационной архитектуры предприятия.
Еще одна ошибка — смешение различных нотаций без установленных правил. BABOK указывает, что разные способы обозначения одних и тех же элементов могут создавать сложности при работе с документацией. В рамках одной инициативы целесообразно выбрать единый стандарт представления.
Практические рекомендации
Перед построением DFD полезно сформулировать объект анализа одним предложением: какая система рассматривается и где проходит ее граница. Это снижает вероятность того, что внутренние элементы одного уровня будут ошибочно представлены как внешние сущности другого.
Следует начинать не с процессов, а с внешнего обмена информацией. Определение отправителей, получателей и содержания потоков помогает построить устойчивый контекст, после чего внутренние преобразования выявляются значительно проще.
Для каждого процесса полезно задавать три контрольных вопроса: какие данные поступают, что с ними изменяется и какие данные должны появиться в результате. Для каждого хранилища — кто записывает информацию и кто ее использует. Для каждой внешней сущности — какие данные она предоставляет или получает.
Названия потоков желательно синхронизировать со словарем данных. Это позволяет связать визуальную модель движения информации с формальным описанием ее содержания.
Наконец, уровень детализации следует выбирать исходя из конкретной аналитической задачи. Если необходимо определить границы интеграционного проекта, контекстная DFD может оказаться достаточной. Если нужно разработать функциональные требования к отдельному компоненту, потребуется дальнейшая декомпозиция.
Ограничения техники
BABOK отмечает несколько существенных ограничений DFD:
Во-первых, при моделировании крупномасштабных систем диаграммы могут становиться сложными и трудными для восприятия заинтересованными сторонами. Поэтому эта техника особенно эффективна при управляемой декомпозиции.
Во-вторых, различия в используемых обозначениях способны создавать проблемы при сопровождении документации.
В-третьих, DFD не показывает последовательность действий. Если необходимо понять порядок выполнения работ, события, развилки или временную логику, требуется другая техника моделирования.
Наконец, сам элемент «процесс» на DFD содержит ограниченную информацию о деятельности и заинтересованных сторонах. Диаграмма показывает преобразование данных, но не раскрывает во всей полноте организационную или процессную логику.
Одновременно BABOK выделяет значительные преимущества техники: DFD может использоваться для исследования процессов и данных, проверки функциональной декомпозиции и моделей данных, определения скоупа системы, связанных систем и интерфейсов. Она помогает обнаруживать дублирующие или неуместные элементы данных, видеть связи с другими системами, определять границы решения, документировать систему и объяснять внутреннюю логику потоков данных.
Вместо заключения
Диаграммы потоков данных позволяют рассматривать систему через движение и преобразование информации. Их ценность заключается не в отображении последовательности операций, а в фиксации источников данных, процессов их преобразования, мест хранения и получателей результата.
В структуре BABOK эта техника состоит из четырех взаимосвязанных элементов: внешних сущностей, хранилищ данных, процессов и потоков данных. Многоуровневая декомпозиция позволяет переходить от контекстного представления системы к детальному анализу отдельных преобразований, а разделение логических и физических DFD помогает отделять необходимое поведение системы от конкретного способа реализации.
На практике DFD особенно полезна в интеграционных и транзакционных решениях, при определении скоупа, исследовании информационных зависимостей и проверке полноты требований. В сочетании со словарем данных, моделированием процессов, функциональной декомпозицией и анализом интерфейсов она дает бизнес-аналитику целостное представление о том, как информация проходит через решение и какую роль она играет в его функционировании.