При построении контекстной диаграммы заказчик включает службу поддержки в границу системы. Как определить, должна ли она быть внутри границы?
Границу системы определяют по предмету анализа и ответственности за поведение, а не по принадлежности к одному подразделению. Служба поддержки находится внутри границы, если её действия или автоматизированные функции входят в создаваемую систему; если она только взаимодействует с системой извне, её показывают как внешнего участника.
Контекстное моделирование появилось как способ управлять сложностью крупных систем и заранее фиксировать их окружение. Исходная проблема состояла в том, что участники проекта по-разному понимали, какие функции относятся к продукту, а какие выполняются внешними людьми, организациями или системами.
Явная граница помогает отделить обязательства разрабатываемой системы от внешних взаимодействий. Это снижает риск незаметного расширения объёма работ и делает интерфейсы между системой и окружением предметом отдельного обсуждения.
Название подразделения само по себе ничего не говорит о границе. Сотрудник службы поддержки может работать внутри создаваемого рабочего места поддержки, а может использовать систему как внешний пользователь, выполняя часть процесса вручную вне неё.
Неверная граница приводит к ошибкам в требованиях: внешнюю операцию начинают считать функцией продукта либо, наоборот, из продукта исключают необходимое поведение. В результате меняются объём разработки, список акторов, ответственность за ошибки и критерии приёмки.
Сначала нужно зафиксировать предмет анализа: конкретный продукт, автоматизируемый сервис или организационный процесс. Затем для каждого участника определить, кто инициирует взаимодействие, кто принимает решения, где выполняется действие и кто отвечает за его результат.
Если система только получает от сотрудника запрос, данные или решение, сотрудник является внешним актором. Если в рамках проекта создаётся функциональность, которая сама реализует действия службы поддержки, эта функциональность входит внутрь границы, а сотрудник может остаться внешним инициатором.
Граница не обязана совпадать с границами компании, отдела или юридического лица. Один и тот же человек может быть внешним актором в модели продукта и внутренним участником в модели более крупного организационного процесса — это зависит от выбранного уровня анализа.
Следует также отделять границу системы от границ ответственности. Внешний участник может быть критически важен для результата процесса, но это не делает его частью системы. На диаграмме нужно явно обозначить передаваемые сообщения, данные или события, а спорные решения подтвердить у владельца продукта и заинтересованных сторон.
Команда разрабатывала портал обработки обращений. Заказчик предложил включить операторов поддержки внутрь границы, потому что они работали в том же подразделении, что и владельцы портала.
Рассмотрели три варианта. Определять границу по организационной структуре было быстро, но смешивало продукт с процессом. Определять её по владению данными было точнее для вопросов ответственности, но не отражало, где выполняются действия. Определять её по автоматизируемому поведению оказалось наиболее устойчивым: портал включал регистрацию, маршрутизацию и контроль обращений, а оператор оставался внешним пользователем.
Выбрали третий вариант. На диаграмме портал показали внутри границы, операторов — снаружи, а их действия описали через взаимодействия с системой. Это позволило отдельно согласовать требования к интерфейсу оператора, ручные регламенты и ответственность за обработку обращения.
Да. Роль определяется не должностью человека, а уровнем и предметом конкретной модели. Например, служба поддержки внешняя для портала обращений, но внутренняя для модели всего процесса обслуживания клиентов. Нельзя переносить границу с одной диаграммы на другую без проверки цели моделирования.
Нет, владение данными является важным фактором, но не единственным критерием. Организация может владеть данными, которые хранятся во внешней системе, или поручить своей системе обрабатывать данные, которыми формально владеет другой участник.
Владение помогает выяснить ответственность, права доступа и правила обмена. Саму границу проводят по тому, какое поведение входит в анализируемую систему и какие функции она обязуется предоставлять.
Для каждой предполагаемой функции нужно задать вопрос: кто выполняет действие, где оно выполняется, какой результат обязуется предоставить система и что произойдёт при отказе внешнего участника. Затем полезно сверить ответы с контекстом, перечнем интеграций, ролями пользователей и ответственными за приёмку.
Если после такой проверки функция одновременно считается внутренней и внешней, модель содержит неуточнённую область ответственности. Её следует вынести на согласование до разработки пользовательских историй и детальных сценариев, иначе последующие требования будут опираться на разные предположения о составе продукта.