Способы представления границ проекта

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

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

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

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

Контекстная диаграмма

Уточнение рамок определяет границу и связи разрабатываемой системы со всем остальным миром. Контекстная диаграмма (context diagram) графически иллюстрирует эту границу. Она определяет оконечные элементы (terminators), расположенные вне системы, которые определенным образом взаимодействуют с ней, а также данные, элементы управления и материальные потоки, протекающие между оконечными элементами и системой. Контекстная диаграмма представляет собой высший уровень абстракции в диаграмме потока данных, разработанной по принципам структурного анализа (Robertson и Robertson, 1994), но эта модель полезна и в других проектах.

Рис. 5-6. Частичная контекстная диаграмма для системы Chemical Tracking System

На рис. 5-6 показана часть контекстной диаграммы для Chemical Tracking System. Вся система изображена кружком; на контекстной диаграмме намеренно не показывают внутренние объекты системы, процессы и данные. «Система» внутри кружка может иметь любую комбинацию ПО, оборудования или человеческих ресурсов. Поэтому она может содержать ручные операции в составе системы в целом. Оконечные элементы в прямоугольниках представляют классы пользователей («Химик» или «Специалист по закупкам»), отделы («Отдел охраны труда и техники безопасности»), другие системы («База данных по обучению») или аппаратные устройства («Считывающее устройство штрих-кода»). Стрелками показаны потоки данных («запрос химиката») или физические элементы («контейнер с химикатом») между системой и оконечными элементами.

Можно было бы ожидать, что поставщики химикатов будут показаны на диаграмме в виде оконечных элементов. Ведь компания направляет заказы для выполнения поставщикам, а те отправляют контейнеры с химикатами и счета в Contoso Pharmaceuticals, отдел же закупок платит поставщикам. Однако эти процессы происходят вне Chemical Tracking System, как часть операций отделов закупок и приобретений. Их отсутствие в контекстной диаграмме показывает, что система не участвует напрямую в размещении заказов у поставщиков, в получении товаров или оплате счетов.

Карта экосистемы

Карта экосистемы (ecosystem map) показывает все системы, связанные с создаваемой системой и взаимодействующие друг с другом, а также природу этих взаимодействий (Beatty и Chen, 2012). Карта экосистемы представляет рамки путем отображения всех систем, которые взаимосвязаны друг с другом и которые может потребоваться изменить при создании вашей системы. Карта экосистемы отличается от контекстных диаграмм тем, что показывает другие системы, связанные с создаваемой вами, в том числе без непосредственных интерфейсов. Зависимые системы можно определить путем выявления тех, что потребляют данные, поступающие из вашей системы. Когда вы достигнете точки, в которой ваш проект не влияет ни на какие дополнительные данные, можно сказать, что вы достигли границы систем, которые относятся к решению.

На рис. 5-7 показана частичная карта экосистемы для Chemical Tracking System. Системы изображены в виде прямоугольников (например, «Система закупок» или «Приемная система»). В этом примере основная система, над которой мы работаем, выделена жирным прямоугольником («Chemical Tracking System»), но если у всех систем равный статус, можно применить такой стиль и к ним. Линии обозначают интерфейсы между системами (например, от системы закупок к Chemical Tracking System). Линии со стрелками и надписями показывают важные порции данных, переходящих от одной системы к другой (например, «Записи об обучении работе с опасными химикатами» передаются от «Корпоративная база данных по обучению» в «Chemical Tracking System»). Некоторых из этих потоков также могут присутствовать на контекстной диаграмме.

Рис. 5-7. Частичная карта экосистемы для Chemical Tracking System

Карта экосистемы на рис. 5-7 показывает, что Chemical Tracking System не подключается напрямую к интерфейсу поддержки отчетов в соответствии с Законом о гигиене и безопасности труда на рабочем месте (OSHA) и требованиями Агентства по охране окружающей среды (EPA). Тем не менее, нужно учитывать, что в Chemical Tracking System могут возникнуть требования, связанные с данными переходящими от нее на интерфейс отчетности через базу данных отдела охраны труда и техники безопасности.

Дерево функций

Дерево функций (feature tree) представляет собой наглядную картину функций, объединенных в логические группы с иерархическим разбиением каждой функций на более мелкие (Beatty и Chen, 2012). Дерево функций предоставляет сжатую иллюстрацию всех запланированных к реализации в проекте функций, что отлично подходит для показа топ-менеджерам, желающим увидеть общую картину всего проекта. Дерево функций может содержать до трех уровней функций, которые обычно называют уровень 1 (L1), уровень 2 (L2) и уровень 3 (L3). Функции уровня L2 являются подфункциями L1, а функции L3 — подфункциями L2.

На рис. 5-8 показана частичная карта экосистемы для Chemical Tracking System. Ствол дерева в середине представляет реализуемый продукт. У каждой функции собственная линия или «ветка», отходящая от ствола. Серые прямоугольники представляют функции уровня L1, такие как «Приобретение химикатов» и «Управление запасами». Линии, отходящие от L1, представляют функции уровня L2: «Поиск» и «Заказ химикатов» являются подфункциями функции «Приобретение химикатов». Подветками ветки L2 являются функции уровня L3: «Поиск в локальных лабораториях» является подфункцией функции «Поиск».

Рис. 5-8 показана частичная карта экосистемы для Chemical Tracking System.

При планировании выпуска или итерации их границы можно определить путем выбора для реализации определенного набора функций и подфункций (Nejmeh и Thomas, 2002; Wiegers, 2006). Функцию можно было реализовать целиком в определенном выпуске, или можно реализовать только ее часть, выбирая определенные подфункции из уровней L2 и L3. В последующих выпусках можно дополнить эти рудиментарные реализации путем добавления большего числа подфункций уровней L2 и L3, пока все функции не будут реализованы в конечном продукте. Так что границы определенного выпуска состоят из определенного набора функций уровней L1, L2 и/или L3 из дерева функций. Выбор функций для реализации в разных выпусках можно отметить цветами или шрифтом. С другой стороны можно создать таблицу с планом подфункций реализуемых в каждом выпуске (Wiegers, 2006).

Список событий

Список событий (event list) перечисляет внешние события, которые могут инициировать определенное поведение в системе. Список событий определяет границы системы путем перечисления возможных бизнес-событий, инициируемых пользователями или инициируемых временем (срабатывание по времени), или сигналов от внешних компонентов, таких как аппаратные устройства. В списке находятся только названия событий — функциональные требования, описывающие, как система реагирует на события, должны описываться в спецификации SRS с использование таблиц событий и реакций на них. Подробнее о таблицах событий и реакций см. главу 12. На рис. 5-9 показан частичный список событий для Chemical Tracking System. В каждом элементе списка указывается, что инициирует событие («Химик» делает что-то или наступает «Время запуска»), а также действие по событию. Список событий также хорошее средство разграничения, потому что можно назначать реализацию определенных событий в конкретном выпуске продукта или итерации разработки.

Рис. 5-9. Частичный список событий для Chemical Tracking System

Обратите внимание, как список событий дополняет контекстную диаграмму и карту экосистемы. Контекстная диаграмма и карта экосистемы в совокупности описывают внешних действующих лиц и задействованные системы, а список событий определяет, как эти действующие лица и системы могут вызвать определенное поведение в создаваемой системе. Список событий можно сверить на предмет корректности и полноты с контекстной диаграммой и картой экосистемы следующим образом:

• Определите, какие внешние сущности в контекстной диаграмме могут являться источниками событий: «Могут ли какие-либо действия химика инициировать определенное поведение системы Chemical Tracking System?»
• Посмотрите, нет ли в карте экосистемы системы, которая может инициировать события в вашей системе.
• Для каждого события определите, если соответствующие ему внешние сущности в контекстной диаграмме или системы в карте экосистемы: «Если контейнер с химикатом может поступить от поставщика, может ли поставщик фигурировать в контекстной диаграмме и/или в карте экосистемы?» Обнаружив несоответствие, посмотрите внимательнее — может в модели отсутствует какой-то элемент. В данном случае в контекстной диаграмме поставщик отсутствует, потому что система Chemical Tracking System не взаимодействует напрямую с поставщиками. Вместе с тем поставщик присутствует в карте экосистемы.