Определение образа продукта вплоть до бизнес-требований

Образ продукта (product vision) выстраивает работу всех заинтересованных лиц в одном направлении. Он описывает, что продукт представляет собой сейчас и каким он станет впоследствии. Границы проекта (project scope) показывают, к какой области конечного долгосрочного образа продукта будет направлен текущий проект. В положении о границах определена черта между тем, что входит в проект и тем, что остается вовне. То есть указанные рамки также определяют ограничения проекта. Более детально эти сведения изложены в базовой версии требований, которую разрабатывает команда для данного проекта. Говоря об образе, мы подразумеваем весь продукт. Он будет изменяться относительно медленно при определении со временем стратегии продукта или развитии бизнес-целей. Границы же относятся к определенному проекту или его итерации, в которых реализуется чуть больше возможностей продукта, как показан на рис. 5-1. Границы более динамичны, чем образ, так как менеджер проекта изменяет содержимое каждой версии в соответствии с графиком, бюджетом, ресурсами и ограничениями качества. Задача планирования заключается в управлении границами определенного проекта (разрабатываемого или расширяемого), как определенным подмножеством большого стратегического образа. Положение об объеме для каждого проекта или каждой итерации или расширения продукта, вероятнее всего будет включено в спецификацию требований к этому ПО, а не в отдельный документ об образе и границах. Для крупных новых проектов необходимо создавать и полный документ об образе и границах проекта, и спецификацию требований. О шаблоне спецификации требований рассказано в главе 10.

Например, федеральное правительственное агентство получило долгосрочный заказ, рассчитанный на пять лет, на разработку массивней информационной системы. Команда определила бизнес-цели и образ системы еще на начальной стадии и за несколько следующих лет никак не меняла их. Было запланировано 15 отдельных выпусков конечной системы. Каждый выпуск создавался как отдельный проект с описанием его собственных границ. Последние должны были соответствовать общему образу продукта и перекликаться с положениями о границах других проектов — это позволяло гарантировать, что ничего не будет пропущено.

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

Анализ предметной области, позволяет выделить ее сущности, определить первоначальные требования к функциональности и определить границы проекта. Модель предметной области должна быть документирована, храниться и поддерживаться в актуальном состоянии до этапа реализации. Для документирования могут быть использованы различные средства (см. тему «Выявление требований»).

Для управления обсуждением области действия проекта можно использовать методику «будет – не будет». В простейшем случае – это список с двумя столбцами, в одном из которых записывается, что проект будет делать, а во втором – что не входит в проект. Такой список, формируется заинтересованными лицами при рассмотрении каждой бизнес-цели проекта, используя любую технику, например метод «мозгового штурма» (см. тему «Выявление требований»). Полученные характеристики позволяют четко определить границы проекта и довольно просто преобразуются в предположения, которые фиксируются в документе.

Функциональная область действия определяет услуги, предоставляемые системой, и вначале до конца неизвестны. В определении услуг системы может помочь список «Действующее лицо/Цель», в котором перечислены все цели пользователя, поддерживаемые системой. При его разработке в первую графу вписываются имена основных действующих лиц, т.е. тех, кто имеет цели, во вторую графу – цель каждого действующего лица, а в третью – приоритет или предположение о том, в какую версию войдет эта услуга. Формы списков приведены на рисунке.

Для определения основных функций продукта можно использовать, например, краткое описание варианта использования (см. тему 4). Описание каждой функции можно представить также в виде списка, состоящего из трех граф: действующее лицо, цель и краткое описание варианта использования.

Анализ предметной области является основой для анализа осуществимости проекта и определения образа (концепции) продукта и границ проекта.