Документ о концепции и границах проекта

Документ о концепции и границах проекта Бизнес-контекст В бизнес-контексте обычно представлены профили основных категорий заинтересованных лиц, приоритеты руководства в проекте, а также сводка некоторых обстоятельств, которые надо учесть при планировании развертывания решения. Рамки и ограничения проекта Когда химик изобретает новую химическую реакцию, которая преобразует одно вещество в другое, он пишет документ, в который входит раздел «Рамки и ограничения», где описывает, что получится и не получится в результате этой реакции. Точно так же для проекта по разработке ПО следует определить его рамки и ограничения. Вам необходимо указать, что может делать система, а что не может. Многие проекты страдают «распуханием границ» — резким ростом из-за активного расширения функциональности продукта. Первый шаг на пути к обузданию распухания границ — определение рамок проекта. Границы проекта определяют концепцию и круг действия предложенного решения. В ограничениях указываются определенные возможности, которые не будут включены в продукт. Рамки и ограничения помогают установить реалистичные ожидания заинтересованных лиц, потому что иногда клиенты запрашивают функции, слишком дорогостоящие или выходящие за предполагаемые границы продукта. Рамки проекта могут представляться различными способами. На самом высоком уровне границы определяются, когда клиент решает, какие бизнес-цели преследовать. На низком уровне границы определяются на уровне функций, пользовательских историй, вариантов использования или событий и реакции на них. В итоге границы определяются через набор функциональных требований, которые планируется реализовать в определенном выпуске или итерации. На каждом уровне границы не должны выходить за рамки более высокого уровня. Например, находящиеся в границах пользовательские требования должны соответствовать бизнес-целям, а функциональные требования — пользовательским требованиям в заданных границах. Концепция проекта В этом документе следует отразить сбалансированную концепцию, удовлетворяющую различных заинтересованных лиц. Она может быть несколько идеалистичной, но должна основываться на существующих или предполагаемых рыночных факторах, архитектуре предприятия, стратегическом направлении развития корпорации или ограничениях ресурсов. Шаблон концепции приложен ниже: • Для [целевая аудитория покупателей]; • Который [положение о потребностях или возможностях]; • Эта (этот) [имя продукта]; • Является [категория продукта]; • Который(ая) [основные функции, ключевое преимущество, основная • Причина [для покупки или использования]; • В отличие от [основной конкурирующий продукт, текущая система или текущий бизнес-процесс]; • Наш продукт [положение об основном отличии и преимуществе нового продукта]. ПРИМЕР Вот как выглядит положение о концепции системы контроля химикатов Chemical Tracking System в Contoso Pharmaceuticals,; ключевые слова выделены полужирным: Для ученых, которым нужно запрашивать контейнеры с химикатом, данная система Chemical Tracking System является информационной системой, которая обеспечит единую точку доступа к складу химикатов и к поставщикам. Система будет знать местоположение каждого контейнера с химикатом в компании, количество химиката в контейнерах и полную историю перемещения и использования каждого контейнера. Эта система сэкономит компании 25% затрат на химикаты в первый год работы, позволив полностью использовать уже полученные химикаты, утилизировать меньшее количество частично израсходованных или просроченных химикатов и применять единую стандартную систему приобретения химикатов. В отличие от действующих сейчас ручных механизмов заказов химикатов наш продукт будет генерировать все отчеты, необходимые для регулирующих органов, в которых требуются сведения об использовании, хранении и утилизации химикатов. Основные функции Опишите основные функции продукта или возможности пользователей, уделив основное внимание тому, что отличает продукт от предыдущей версии или конкурирующих продуктов. Подумайте, как пользователи будут работать с этими функциями, чтобы убедиться, что список функций полон и не содержит ненужных функций, которые интересны, но не приносят пользы пользователям. Назначьте каждой функции уникальное и постоянное название, чтобы ее можно было отслеживать в других компонентах системы. Можно создать древовидную схему, как показано далее в этой главе. ПРИМЕР Основные функции FE-1 Заказ и оплата блюд из меню кафетерия для получения в кафетерии или с доставкой. FE-2 Заказ и оплата блюд с доставкой из близлежащих ресторанов. FE-3 Создание, просмотр, изменение и удаление одинарной или регулярной заявок на питание или на ежедневные специальные блюда. FE-4 Создание, просмотр, изменение и удаление меню кафетерия. FE-5 Просмотр списка ингредиентов и сведения о питательности блюд в меню кафетерия. FE-6 Обеспечение доступа к системе через корпоративную интрасеть, смартфон, планшет или через внешнее подключение к Интернету для авторизованных сотрудников. Объем первоначально запланированной версии Обобщает основные запланированные функции, включенные в первоначальную версию продукта. Границы проекта обычно определяются как набор функций, но их можно также определять в терминах пользовательских историй, вариантов использования, потоков вариантов использования или внешних событий. Также можно описать характеристики качества, которые позволят продукту предоставлять предполагаемые преимущества различным классам пользователей. Если ваша задача — сосредоточиться на разработке и уложиться в график, вам следует избегать искушения включить в версию 1.0 каждую функцию, которая когда-нибудь в будущем может понадобиться какому-то потенциальному покупателю. Распухание кода и сдвиг графика — типичные исходы такого коварного набивания объема. Сосредоточьтесь на наиболее ценных функциях, имеющих максимально приемлемую стоимость, годных для самой широкой целевой аудитории, которые удастся создать как можно раньше. В качестве иллюстрации приведу недавний проект, в котором команда решила, что пользователи должны иметь возможность запускать собственную службу доставки в первой версии ПО. Версия 1 не обязательно должна быть быстрой, красиво оформленной или легкой в использовании, но она должна быть надежной; этим принципам команда следовала четко. Первая версия системы выполняет лишь основные задачи. В будущие выпуски будут включены дополнительные функции, возможности и средства, обеспечивающие легкость и простоту использования. Но в первом выпуске важно не забыть о нефункциональных требованиях. Тех, что непосредственно влияют на архитектуру, их особенно важно установить с самого начала. Переделка архитектуры для исправления недостатков качества может стоить столько же, сколько написание продукта с нуля. Объем последующих версий Если вы ожидаете поэтапную эволюцию продукта или если используете итеративную модель разработки, создайте план выпуска, в котором укажите, какие функции будут отложены и желательные сроки последующих выпусков. В последующих версиях вы сможете реализовать дополнительные варианты использования и функции и расширить возможности первоначальных вариантов использования и функций. Чем дальше вы заглядываете, тем более расплывчатыми будут границы проекта. Вам наверняка придется передвинуть функциональность с одного запланированного выпуска до другого и, возможно, добавлять незапланированные функции. Короткие циклы выпусков часто предоставляют удобные случаи для накопления знаний, основанных на отзывах клиентов. ПРИМЕР Состав первого и последующих выпусков системы Функция Выпуск 1 Выпуск 2 Выпуск 3 FE-1. Заказ в кафетерии Только стандартные функции из меню обедов; оплата заказов производится только посредством удержания из зарплаты Прием платежа кредитной или дебетовой картой Прием заказов на завтрак и ужин FE-2. Заказы из ресторанов Не реализована Блюда доставляются только на территории компании Реализована полностью FE-3. Подписки на стандартные блюда Не реализована Реализация, если позволит время Реализована полностью FE-4. Меню Создание и просмотр меню Модификация, удаление и архивирование меню FE-5. Список ингредиентов Не реализована Реализована полностью FE-6. Доступ к системе Интрасеть и доступ через Интернет извне Приложения для телефонов и планшетов с iOS и Android Приложения для телефонов и планшетов с Windows Phone Ограничения и исключения Перечислите все возможности или характеристики, которых могут ожидать заинтересованные в проекте лица, но включение которых в продукт или в определенную версию не запланировано. Перечислите изъятые элементы, чтобы не забыть решения по границам проекта. Если пользователь запросил возможность доступа к системе с телефона, когда он не находится на рабочем месте, и эта функция была признанной не входящей в границы проекта, тогда четко запишите в соответствующем разделе: «Новая система не поддерживает доступа с мобильных устройств». ПРИМЕР Ограничения и исключения LI-1 На некоторые пункты меню кафетерия доставка не распространяется, поэтому блюда, доступные клиентам Cafeteria Ordering System, будут подмножеством полных меню кафетерия. LI-2 Cafeteria Ordering System применяется только для кафетерия главного офиса Process Impact в г. Клакамас, штат Орегон. Профили заинтересованных лиц Заинтересованными в проекте лицами (stakeholders) называются отдельные лица, группы или организации, которые активно вовлечены в проект, на которых влияет результат проекта и которые сами могут влиять на этот результат. Профили заинтересованных лиц описывают различные категории клиентов и других ключевых лиц, заинтересованных в этом проекте. Вам не нужно описывать каждую группу заинтересованных лиц, например юристов, которые должны проверять соответствие надлежащим законам. Сферой вашего интереса должны стать различные группы клиентов, целевые рыночные сегменты и различные классы пользователей, входящих в эти сегменты. В профиль каждого заинтересованного в проекте лица включается следующая информация: • основная ценность или преимущество, которое продукт принесет заинтересованным лицам, и то, как продукт удовлетворит покупателей. Ценность для заинтересованных лиц представляют: • повышенная производительность; • меньшее количество переделок; • снижение себестоимости; • ускорение бизнес-процессов; • автоматизация задач, ранее выполнявшихся вручную; • возможность выполнять совершенно новые задачи; • соответствие соответствующим стандартам и правилам; • лучшая, по сравнению с текущими продуктами, легкость и простота использования; • их вероятное отношение к продукту; • самые важные для них функции и характеристики; • все известные ограничения, которые должны быть соблюдены. Можно включить поименный список ключевых заинтересованных лиц для каждого профиля или структурную схему организации, показывающую отношения между заинтересованными лицами в организации. Способы представления границ проекта Описанные в этом разделе модели могут использоваться для различного представления границ проекта. Модели можно включать в документ концепции и границ или хранить в другом месте для использования в дальнейшем. Задача таких инструментов, как контекстная диаграмма, карта экосистемы, дерево функций и список событий, — поощрять прозрачные и точные механизмы общения между заинтересованными лицами проекта. Такая прозрачность важнее догматичного соблюдения всех правил для создания «правильной» диаграммы. Однако мы настоятельно рекомендуем придерживаться применяемой в следующих примерах нотации как стандарту создания диаграмм. Например, если в контекстной диаграмме вы используете для представления системы треугольники вместо круга, а для представления внешних сущностей — овалы вместо прямоугольников, вашим коллегам будет тяжело читать такую «нестандартную» диаграмму. Для наглядного представления границ проекта чаще всего используют контекстные диаграммы, карты экосистемы, дерева функций и списки событий. Но применяются и другие методы. Выявление затрагиваемых бизнес-процессов также помогает определять границы проекта. Диаграммы вариантов использования позволяют проиллюстрировать границу между вариантами использования и действующими лицами. Контекстная диаграмма Уточнение рамок определяет границу и связи разрабатываемой системы со всем остальным миром. Контекстная диаграмма (context diagram) графически иллюстрирует эту границу. Она определяет оконечные элементы (terminators), расположенные вне системы, которые определенным образом взаимодействуют с ней, а также данные, элементы управления и материальные потоки, протекающие между оконечными элементами и системой. Контекстная диаграмма представляет собой высший уровень абстракции в диаграмме потока данных, разработанной по принципам структурного анализа, но эта модель полезна и в других проектах. ПРИМЕР Частичная карта экосистемы для Chemical Tracking System Выше показана часть контекстной диаграммы для Chemical Tracking System. Вся система изображена кружком; на контекстной диаграмме намеренно не показывают внутренние объекты системы, процессы и данные. «Система» внутри кружка может иметь любую комбинацию ПО, оборудования или человеческих ресурсов. Поэтому она может содержать ручные операции в составе системы в целом. Оконечные элементы в прямоугольниках представляют классы пользователей («Химик» или «Специалист по закупкам»), отделы («Отдел охраны труда и техники безопасности»), другие системы («База данных по обучению») или аппаратные устройства («Считывающее устройство штрих- кода»). Стрелками показаны потоки данных («запрос химиката») или физические элементы («контейнер с химикатом») между системой и оконечными элементами. Можно было бы ожидать, что поставщики химикатов будут показаны на диаграмме в виде оконечных элементов. Ведь компания направляет заказы для выполнения поставщикам, а те отправляют контейнеры с химикатами и счета в Contoso Pharmaceuticals, отдел же закупок платит поставщикам. Однако эти процессы происходят вне Chemical Tracking System, как часть операций отделов закупок и приобретений. Их отсутствие в контекстной диаграмме показывает, что система не участвует напрямую в размещении заказов у поставщиков, в получении товаров или оплате счетов. Карта экосистемы Карта экосистемы (ecosystem map) показывает все системы, связанные с создаваемой системой и взаимодействующие друг с другом, а также природу этих взаимодействий. Карта экосистемы представляет рамки путем отображения всех систем, которые взаимосвязаны друг с другом и которые может потребоваться изменить при создании вашей системы. Карта экосистемы отличается от контекстных диаграмм тем, что показывает другие системы, связанные с создаваемой вами, в том числе без непосредственных интерфейсов. Зависимые системы можно определить путем выявления тех, что потребляют данные, поступающие из вашей системы. Когда вы достигнете точки, в которой ваш проект не влияет ни на какие дополнительные данные, можно сказать, что вы достигли границы систем, которые относятся к решению. ПРИМЕР Частичная карта экосистемы для Chemical Tracking System Системы изображены в виде прямоугольников (например, «Система закупок» или «Приемная система»). В этом примере основная система, над которой мы работаем, выделена жирным прямоугольником («Chemical Tracking System»), но если у всех систем равный статус, можно применить такой стиль и к ним. Линии обозначают интерфейсы между системами (например, от системы закупок к Chemical Tracking System). Линии со стрелками и надписями показывают важные порции данных, переходящих от одной системы к другой (например, «Записи об обучении работе с опасными химикатами» передаются от «Корпоративная база данных по обучению» в «Chemical Tracking System»). Некоторых из этих потоков также могут присутствовать на контекстной диаграмме. Дерево функций Дерево функций (feature tree) представляет собой наглядную картину функций, объединенных в логические группы с иерархическим разбиением каждой функций на более мелкие (Beatty и Chen, 2012). Дерево функций предоставляет сжатую иллюстрацию всех запланированных к реализации в проекте функций, что отлично подходит для показа топ- менеджерам, желающим увидеть общую картину всего проекта. Дерево функций может содержать до трех уровней функций, которые обычно называют уровень 1 (L1), уровень 2 (L2) и уровень 3 (L3). Функции уровня L2 являются подфункциями L1, а функции L3 — подфункциями L2. На рис. ниже показана частичная карта экосистемы для Chemical Tracking System. Ствол дерева в середине представляет реализуемый продукт. У каждой функции собственная линия или «ветка», отходящая от ствола. Серые прямоугольники представляют функции уровня L1, такие как «Приобретение химикатов» и «Управление запасами». Линии, отходящие от L1, представляют функции уровня L2: «Поиск» и «Заказ химикатов» являются подфункциями функции «Приобретение химикатов». Подветками ветки L2 являются функции уровня L3: «Поиск в локальных лабораториях» является подфункцией функции «Поиск». ПРИМЕР Частичная карта функций для системы Chemical Tracking System При планировании выпуска или итерации их границы можно определить путем выбора для реализации определенного набора функций и подфункций. Функцию можно было реализовать целиком в определенном выпуске, или можно реализовать только ее часть, выбирая определенные подфункции из уровней L2 и L3. В последующих выпусках можно дополнить эти рудиментарные реализации путем добавления большего числа подфункций уровней L2 и L3, пока все функции не будут реализованы в конечном продукте. Так что границы определенного выпуска состоят из определенного набора функций уровней L1, L2 и/или L3 из дерева функций. Выбор функций для реализации в разных выпусках можно отметить цветами или шрифтом. С другой стороны, можно создать таблицу с планом подфункций реализуемых в каждом выпуске. Список событий Список событий (event list) перечисляет внешние события, которые могут инициировать определенное поведение в системе. Список событий определяет границы системы путем перечисления возможных бизнес-событий, инициируемых пользователями или инициируемых временем (срабатывание по времени), или сигналов от внешних компонентов, таких как аппаратные устройства. В списке находятся только названия событий — функциональные требования, описывающие, как система реагирует на события, должны описываться в спецификации SRS с использование таблиц событий и реакций на них. На рис. 1-8 показан частичный список событий для Chemical Tracking System. В каждом элементе списка указывается, что инициирует событие («Химик» делает что-то или наступает «Время запуска»), а также действие по событию. Список событий также хорошее средство разграничения, потому что можно назначать реализацию определенных событий в конкретном выпуске продукта или итерации разработки. ПРИМЕР Частичный список событий для Chemical Tracking System Внешние события для Chemical Tracking System • Химик разместил заказ химиката. • Просканирован штрих-код контейнера с химикатом. • Наступило время генерации отчетов OSHA. • Поставщик выпустил новый каталог химикатов. • Новый специализированный химикат добавлен в систему. • Поставщик отменил заказ химиката. • Химик запросил свой отчет о контактах с химикатами. • Получена спецификация безопасности материалов из Управления по охране окружающей среды (EPA). • В список предпочтительных поставщиков добавлен новый поставщик. • Получен контейнер с химикатами от поставщика. Обратите внимание, как список событий дополняет контекстную диаграмму и карту экосистемы. Контекстная диаграмма и карта экосистемы в совокупности описывают внешних действующих лиц и задействованные системы, а список событий определяет, как эти действующие лица и системы могут вызвать определенное поведение в создаваемой системе. Список событий можно сверить на предмет корректности и полноты с контекстной диаграммой и картой экосистемы следующим образом: • Определите, какие внешние сущности в контекстной диаграмме могут являться источниками событий: «Могут ли какие-либо действия химика инициировать определенное поведение системы Chemical Tracking System?» • Посмотрите, нет ли в карте экосистемы системы, которая может инициировать события в вашей системе. • Для каждого события определите, если соответствующие ему внешние сущности в контекстной диаграмме или системы в карте экосистемы: «Если контейнер с химикатом может поступить от поставщика, может ли поставщик фигурировать в контекстной диаграмме и/или в карте экосистемы?» Обнаружив несоответствие, посмотрите внимательнее — может в модели отсутствует какой-то элемент. В данном случае в контекстной диаграмме поставщик отсутствует, потому что система Chemical Tracking System не взаимодействует напрямую с поставщиками. Вместе с тем поставщик присутствует в карте экосистемы.