Документ об образе и границах проекта (Product Vision)
Сведения об образе и границах проекта должны быть оформлены в виде отдельного документа, которым владеют лица, финансирующие проект.
Документ об образе и границах проекта определяет границу и связи системы с остальным миром.
Образ продукта (product vision) – это определение стратегического образа системы, позволяющей выполнять бизнес-задачи.
Образ продукта выстраивает работу всех заинтересованных лиц в одном направлении и описывает, что продукт – сейчас и каким он станет впоследствии. Этот образ будет основой принятия решений на протяжении всего жизненного цикла продукта, поскольку он содержит описание долгосрочных целей и назначения продукта, которое удовлетворяет интересы различных заинтересованных лиц, основано на существующих или прогнозируемых рыночных факторах, учитывает структуру и стратегию развития организации.
Границы проекта (project scope) показывают, к какой области конечного долгосрочного образа продукта будет направлен текущий проект.
Границы проекта могут относиться к определенной итерации проекта или версии продукта. В положении о границах определена черта между тем, что входит в проект, и тем, что остается вовне. То есть указанные рамки также ограничивают проект. Более детально эти сведения изложены в базовой версии требований, которую разрабатывает для данного проекта команда.
Документ об образе и границах проекта – это описание исходных данных проекта в заданной структуре. Стандартного шаблона такого документа нет, но есть основные разделы, которые должны быть прописаны. Этот документ также может называться уставом проекта, описанием бизнес-требований, документом о концепции и границах проекта.
Информация, которую должен содержать документ об образе и границах проекта
1. Обоснование и содержание нового продукта, а также причины его создания.
2. Описание ситуации на рынке, где продукту придется конкурировать с другими.
3. Описание (для корпоративной системы) бизнес-проблемы, которую решает продукт, среды его использования, сравнительная оценка продукта и его конкурентов, преимущества продукта.
4. Описание бизнес-целей и критерии оценки их достижения в количественном и измеряемом виде, рисков, возможных потерь от них, способов минимизации рисков.
1. Целевая аудитория пользователей, их потребности или возможности.
2. Имя, категория и ключевое преимущество. Это основы для использования.
3. Отличия от конкурентов или текущего бизнес-процесса, описание основного отличия и преимущества продукта.
4. Основные функции и возможности продукта, предоставляемые пользователю. Функции и возможности необходимо идентифицировать, а те из них, которые отличают продукт от продукта конкурентов, – подчеркнуть.
5. Предположения и зависимости. Перечисляются зависимости проекта от внешних факторов, документируются все предположения, сделанные заинтересованными лицами при разработке данного документа.
Описывается объем первоначальной версии продукта. Туда включаются наиболее важные для широкой аудитории функции, которые стоит реализовать как можно раньше, и объемы последующих версий продукта. Здесь же перечисляются возможности и характеристики продукта, ожидаемые заинтересованными лицами, но не предусмотренные для включения в продукт или его определенную версию.
Описываются профили заинтересованных лиц. Они включают данные об основной ценности или преимуществе продукта, о вероятном отношении к продукту. Перечисляются наиболее интересные функции, характеристики и другие преимущества нового продукта.
Перечисляются приоритеты факторов, которыми может оперировать менеджер проекта для достижения успеха. Например, каждый проект имеет пять измеряемых параметров: объем (функции), качество, график, затраты и кадры. Каждый из параметров может относиться к одной из категорий:
• ограничение – лимитирующий фактор, в рамках которого должен оперировать менеджер;
• ключевой фактор – важный фактор успеха, ограниченно гибкий при изменениях;
• степень свободы – фактор, который можно изменять в некоторой степени.
Тогда определение приоритетов – это соотнесение параметров и категорий параметров.
Приводится описание среды, в которой будет использоваться система, и определяются требования к доступности, надежности, производительности и целостности.
Документ об образе и границе проекта определяет границу и связи системы с остальным миром. Использование в документе контекстной диаграммы позволяет графически иллюстрировать эту границу, описывая внешние сущности, которые располагаются вне системы, а также потоки данных: управляющие и материальные потоки, протекающие между системой и внешним миром. Диаграммы позволяют уточнить взаимодействие между заинтересованными в проекте лицами.
План управления требованиями (ПУТ) и план управления документами (ПУД)
План управления требованиями (ПУТ) – это контракт между аналитиком и менеджером проекта на выполнение аналитических работ. ПУТ фиксирует информацию о том, какие требования разрабатываются в проекте, как и кто ими управляет и как проводится согласование и утверждение требований.
Ниже приведен возможный состав ПУТ.
1. Введение.
2. Общее описание методологии анализа, разработки и управления требованиями в проекте.
3. Системный анализ и моделирование.
a. Обзор основных моделей системного анализа.
b. Управление артефактами (моделями) системного анализа.
4. Разработка требований.
a. Типы требований.
b. Типизация нефункциональных требований.
c. Атрибуты требования.
5. Управление требованиями.
a. Методология управления.
i. Атрибуты требований.
ii. Полномочия по работе с требованиями.
iii. Обсуждение требований.
iv. Согласование требований.
v. Утверждение требований.
b. Жизненный цикл требований.
i. Запросы заинтересованного лица.
ii. Все остальные типы требований.
c. Трассировка требований.
6. Управление изменениями в требованиях.
a. Обработка запроса на изменение.
b. Базовые версии требований (baselines) в проекте.
7. Спецификации требований.
8. Управление процессом анализа и разработки требований.
a. Список основных артефактов и деятельностей по управлению требованиями.
b. Передача знаний бизнес-аналитику.
c. Обучение и передача знаний системному аналитику.
d. Постоянные улучшения процесса анализа и разработки требований.
План управления документами (ПУД) включает в себя информацию о том, какие проектные артефакты должны создаваться на каждом этапе проекта и в каком состоянии они должны находиться, кто отвечает за их согласование и утверждение, кто несет ответственность за артефакты, даты их готовности и т. д. и т. п.
Документирование вариантов использования
Существует два способа для того, чтобы представить этапы взаимодействия пользователя и системы, которые и составляют основу варианта использования.
1. Составить пронумерованный список этапов с указанием того, какой элемент (система или определенное действующее лицо) выполняет каждый шаг. Аналогично описать альтернативные направления и исключения, для которых показан этап нормального направления развития, момент появления ответвления или этапа, где возможно исключение.
2. Описать процесс в виде таблицы из двух столбцов. Действия лица показать в левом столбце, а реакцию системы – в правом. Цифры указывают на последовательность этапов диалога. Эта схема отлично работает, когда с системой взаимодействует только один пользователь.
При документировании вариантов использования необходимо сосредоточиться на выявлении важнейших из них.
Важнейший вариант использования (essential use case) – упрощенное, обобщенное, абстрактное, не зависящее от технологии и реализации описание одной задачи или взаимодействия, в котором воплощена цель или намерения, лежащие в основе взаимодействия.
Фрагмент описания варианта использования «Запросить химикат»
Это означает, что следует сосредоточиться на задаче, которую необходимо выполнить пользователю, и возможностях системы для выполнения этой задачи. Важнейшие варианты использования характеризуются более высоким уровнем абстракции, чем конкретные варианты использования (concrete use cases), которые описывают определенные действия пользователя для работы с системой.
В качестве примера рассмотрим два способа начала реализации пользователем варианта использования «Запросить химикат».
1. Конкретный вариант использования – «Введите номер ID химиката».
2. Важнейший вариант использования – «Укажите необходимый химикат».
Формулировка на важнейшем уровне позволяет пользователю выполнить задачу несколькими способами: ввести номер ID химиката, импортировать химическую структуру из файла, нарисовать структуру на экране с помощью мыши, выбрать химикат из списка и т. д. Независимые от реализации важнейшие варианты использования более пригодны для повторных применений, чем конкретные варианты использования.
Например, если пользователь говорит: «По умолчанию это должно быть…», значит, он описывает нормальное направление развития варианта использования. Фраза «Необходимо, чтобы пользователь также смог…» предполагает обсуждение альтернативного направления. Многие условия исключений можно выяснить с помощью вопроса «Что должно произойти, если в текущий момент БД отключена?» или «Что, если этого химиката нет в продаже?»
Когда вариант использования описан и никто уже не предлагает дополнительных вариантов, исключений или специальных требований, можно переходить к следующему варианту использования. Не стоит рассматривать все варианты использования за одно обсуждение, превраща