3.5. Артефакты процесса управления требованиями.

Артефакты, используемые при анализе проблемы, приведены на рис 3.7.

Рисунок 3.7. Артефакты потока работ «Анализ проблемы»

Все операции, выполняемые в рамках анализа проблемы, реализуются системным аналитиком. Для решения некоторых из них он взаимодействует с представителями заинтересованных сторон, представленными на рисунке в виде производственных актеров с именами «Совладелец», «Заказчик», «Конечный пользователь». Кроме того, используется ряд артефактов, содержащих входные данные для решения задачи, и производится набор артефактов, содержащих результат выполнения работ.

Рассмотрим деятельность системного аналитика, связанную с формированием артефакта под названием «Глоссарий терминов». Целью его работы является разработка документа, который может быть использован во всех текстовых описаниях системы, особенно при создании текстовых описаний прецедентов.

Для этого системному аналитику рекомендуется выделить:

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

• события реального мира, о которых должна знать создаваемая информационная система.

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

Обычно каждый термин глоссария представляется существительным и его определением. При этом все существительные заносятся в единственном числе: «заказ», «задача», «поставка», а не «заказы», «задачи», «поставки».

Кроме того, участники большинства проектов стремятся разработать специальный язык или систему сокращений. Чаще всего сокращения бывают мнемоническими, например АИС (автоматизированная информационная система), ГОСТ (государственный стандарт), АСУ (автоматизированная система управления) и т.д. Хорошо организованный глоссарий содержит список таких сокращений и их расшифровку, чтобы помочь понять участникам проекта язык прикладной области разработки. В целом, рекомендации по организации глоссария сводятся к следующему:

• необходимо воздерживаться от использования терминов, имеющих различный смысл в различных ситуациях;

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

Rational Unified Process позволяет рассматривает глоссарий терминов как неформальный словарь данных предметной области. Подробнее о создании и использовании словаря данных можно прочесть в книге Карла Вигерса «Разработка требований к программному обеспечению» [13].

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

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

Рисунок 3.8. Определение актеров и прецедентов системы с использованием модели категорий производства.

Если целью проекта является создание системы, которая бы полностью автоматизи­ровала производственные процессы (например, приложения электронной коммерции), то к числу производственных исполнителей актеры системы относиться уже не будут. При создании приложений такого типа приходится сталкиваться с изменением способа ведения дел. Обязанности производственных исполнителей передаются производственным актерам. Пример такой ситуации приведен на рис. 3.9.

Рисунок 3.9. Определение актеров и прецедентов системы при условии изменения способа реализации производственного процесса.

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

Цель документа «Запросы заинтересованных сторон» состоит в том, чтобы зафиксировать запросы к выполняемому проекту так, как они были первоначально сформулированы. Хотя за создание этого документа отвечает системный аналитик, ему помогают специалист по маркетингу и представители заинтересованных сторон (конечные пользователи, заказчики и т.д.).

Кроме запросов заинтересованных сторон, документ должен содержать ссылки на все внешние источники, налагающие ограничения на создаваемую систему. Примерами таких источников являются:

• Инструкции по работе

• Бизнес-правила

• Законы и другие правовые акты

• Наследуемые системы

• Бизнес-модели

• Любые результаты, полученные в ходе проведения семинаров, посвященных требованиям.

Как и для других артефактов, для «Запросов заинтересованных сторон» Rational Unified Process предлагает ряд вопросов, положительный ответ на которые свидетельствует о высоком качестве артефакта:

• Правильно ли выбраны представители заинтересованных сторон, привлеченные к созданию этого артефакта?

• Все ли прошлые запросы были пересмотрены для текущего выпуска системы?

• Правильно ли был установлен набор источников информации?

• Подходящие ли методы применялись для извлечения информации?

• Достаточно ли полно отражает содержание этого артефакта все аспекты, представляющие интерес для проекта?

Используя в качестве входных данных сведения, содержащиеся в модели прецедентов информационной системы, документах «Запросы заинтересованных сторон» и «Бизнес-правила» системные аналитик имеет возможность приступить к разработке документа видения.

Документ видения (Vision document), называемый в некоторых источниках документом-концепцией [5] сочетает в себе некоторые основные элементы документа маркетинговых требований и документа требований к продукту.

Филипп Крачтен (Philippe Kruchten) как-то сказал: "Если бы мне разрешили разработать только один документ, модель или другой артефакт для поддержки программного проекта, я бы выбрал краткий, хорошо сформулированный документ видения".

Документ-концепция описывает приложение в общих чертах, а также содержит опи­сания целевых рынков, пользователей системы и функций приложения. Сфера действия документа видения распространяется на два верхних уровня пирамиды требований (рис. 3.3), благодаря чему он охватывает как проблему, так и решение. Кроме того, документ видения для программного продукта служит основой для достижения со­гласия между тремя сообществами заинтересованных сторон:

• отделом маркетинга, который выступает в качестве доверенного лица заказчика и пользователя и отвечает за успех продукта после реализации.

• командой проекта, разрабатывающей приложение.

• руководством, которое несет ответственность за бизнес-результат.

Документ видения является мощным средством, так как содержит описание всех существенных аспектов продукта с различных точек зрения в краткой, абстрактной, доступной и управляемой форме.

Структура документа видения имеет следующий вид:

1. Введение.

В данном разделе предлагается общий обзор документа-концепции.

1.1. Назначение документа-концепции.

В данном разделе фиксируются, анализируются и задаются высоко­уровневые потребности пользователей и функции системы.

1.2. Краткое описание продукта.

Формулируется цель создания приложения, и новые функции, предоставляемые системой.

1.3. Ссылки.

Приводится полный список всех документов, упоминаемых в документе видения.

2. Описание пользователей

Кратко представлены общие сведения о пользователях системы. 2.1. Данные о пользователе / рынке

Кратко представлены основные данные о рынке, которые мотивируют решения относительно продукта.

2.2. Типы пользователей.

Кратко описываются будущие пользователи системы.

2.3. Среда пользователя.

2.4. Основные потребности пользователей.

Перечисляются основные проблемы или потребности пользователей.

2.5. Альтернативы и конкуренты.

Выявляются все приемлемые (с точки зрения пользователя) альтернати­вы.

3. Краткое описание продукта

3.1. Общий вид продукта

Предлагается блок-схема продукта или системы и ее интерфейсов с внешней средой.

3.2. Определение позиции продукта на рынке

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

3.3. Характеристика возможностей

Перечисляются основные возможности и функции, которые будут предоставлены продуктом.

3.4. Предположения и зависимости

3.5. Затраты и цены

4. Атрибуты функций

Описываются атрибуты функций, которые будут использоваться для оценки, отслеживания, задания приоритетов и управления функциями.

5. Функции продукта

В данном разделе перечисляются функции продукта.

6. Ключевые прецеденты

Описываются основные прецеденты, которые важны с точки зрения ар­хитектуры или наиболее полезны для того, чтобы помочь читателю по­нять, как будет использоваться система.

7. Другие требования к продукту

7.1. Применяемые стандарты

Перечисляются все стандарты, которым должен соответствовать продукт.

7.2. Системные требования

Задаются все системные требования, которым должно соответствовать приложение.

7.3. Лицензирование и установка

Описываются все инсталляционные требования, которые оказывают влияние на создание программного кода или вызывают потребность в создании отдельного инсталляционного программного обеспечения.

7.4. Требования к производительности

Этот раздел используется для подробного описания требований к произ­водительности.

8. Требования к документации

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

8.1. Руководство пользователя

Описывается цель и содержание руководства пользователя.

8.2. Интерактивные подсказки

Требования к интерактивным подсказкам, средствам предупреждения и т.п.

8.3. Руководства по инсталляции, конфигурация и файлы "Read Me"

8.4. Маркировка и упаковка

9. Глоссарий

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

Для этого документ видения должен быть как можно более кратким, сжатым и излагать вещи "по существу". При создании первой версии документа это не слож­но, так как все пункты в перечне будут новыми для данного проекта. В последующие версии документа видения повторно записывать информацию, не претерпевшую измене­ний (описание функций, пользователей и рынков) представляется малоэффективным. Для решения данной проблемы предлагается использовать документ изменений видения (Delta Vision Document).

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

• общая информация и введение;

• сведения о пользователях системы и описание рынков;

• описание функций, которые предполагается реализовать в версии 1.0;

• прочие требования;

• будущие функции, которые были выявлены, но не вошли в версию 1.0.

Рисунок 3.10. Документ видения системы для версии 1.0.

По мере развития проекта будут выявляться и добавляться новые функции, а функции, выявленные ранее, будут описаны более полно. Таким образом, документ разрастается, и одновременно возрастает его значение для команды. В данной ситуации представляется логичным выявить будущие функции, которые включены в документ для версии системы 1.0, но не реализованы, и запланировать их для реализации в версии системы 2.0. Можно запланировать проведение дополнительного совещания, посвященного требованиям или осуществление другого процесса выявления требований с целью обнаружения новых функций, за­планированных для реализации в версии 2.0, а также тех, которые нужно будет внести в документ в качестве нового множества будущих функций. Некоторые из этих функций, основанные на обратной реакции заказчика, уже будут очевидны, другие возникнут как следствие по­лученного командой опыта. В любом случае эти вновь обнаруженные функции следует записать в документ видения для версии 2.0 как запланированные для немедленной реализации либо как будущие относительно версии 2.0. функции.

Может оказаться, что некоторые реализованные в версии 1.0 функции не достигают по­ставленной цели (возможно, из-за того, что внешняя среда изменилась за время разработки и функция больше не нужна или должна быть заменена новой, либо из-за того, что она просто не нужна клиентам, хотя они предполагали обратное). В любом случае скорее всего обнаружится, что в следующей версии некоторые функции необходимо удалить. Как отразить эти "антитребования"? В данной ситуации нужно просто использовать документ видения для указания того, что определенная функция должна быть удалена из следующей версии.

В процессе работы документ постоянно растет. Это естественно, так как он определя­ет растущую систему. К сожалению, может случиться, что со временем документ будет все труднее читать и понимать, так как теперь он гораздо объемнее и содержит много информации, которая не претерпела изменений со времени предыдущей реализа­ции. Например, определение позиции продукта и целевые пользователи, скорее всего, остались неизменными, как и 25-50 функций, реализованных в версии 1.0, которые перекочуют в документ видения для версии 2.0.

Поэтому предлагается вести документ изменений видения (Delta Vision Document). В нем отражается только то, что изменилось. Дополнительные сведения, включаемые в документ, напоминают команде концепцию проекта и помогают войти в курс дела ее новым членам.

Таким образом, формируется документ изменений, в котором основное внимание уделяется тому, что нового включено в очередную версию и что отличает ее от предыдущей версии документа видения (рис 3.11.).

Рисунок 3.11. Документ видения системы для версии 1.0.

• Документ видения для версии системы 1.0 является точкой отсчета: здесь представ­лено все, что заинтересованной стороне необходимо знать о проекте.

• Delta Vision 2.0 определяет то, что отличает вторую версию системы от первой.

• Объединение этих документов задает полное определение версии 2.0 системы.

Совместное использование упомянутых документов, несомненно, полезно для новых членов команды. Однако в этом случае приходится читать о функциях системы версии 1.0, которых уже нет в версии 2.0, так как они были позднее удалены, и нужно всегда отслеживать эти изменения при воссозда­нии полного определения.

Если это необходимо, можно достаточно просто соединить содержимое документа видения системы версии 1.0 и изменения видения для системы версии 2.0 в новый документ видения системы версии 2.0, который представляет все­объемлющую и полную картину проекта. В других обстоятельствах может оказаться удобным использовать документ изменения видения только при относительно небольших модификациях (таких, как версии системы 1.1 и 1.2) и начинать все сначала и пересматривать определение продукта в целом для каждой крупной реализации {версии 2.0 или 3.0). В любом случае применение документа изменения видения поможет лучше справиться с процессом управления требованиями, так как позволит команде сконцен­трироваться на «том, что действительно важно» на каждом конкретном этапе.

Крайне редко практикуется документирование полных требований крупномасштабной существующей системы. Одна из сложнейших проблем при управлении требованиями состоит в применении методов управления требованиями к эволюции существующих IТ-систем. Крайне редко существуют полные и адекватные спецификации требований для миллионов строк кода и сотен человеко-лет трудозатрат, отражением которых являются эти системы. Так­же непрактично останавливаться и повторно документировать прошлое. При этом мож­но упустить время и не выполнить свою задачу, записывая исторические требования то­гда, когда следовало писать код!

Таким образом, если приходится начинать с нуля или с минимальной документации, следует использовать все имеющиеся в распоряжении ресурсы (программный код, спецификации, знания членов команды о предыстории), чтобы прийти к пониманию то­го, что система делает в настоящий момент. Затем рекомендуется применить процесс создания документа Delta Vision и задать функции и прецеденты, описывающие изменения, которые планируется вносить в существующую систему. Следуя этому процессу, можно скон­центрироваться на том, что нового планируется в данной реализации и что отличает ее от предыдущих реализаций. В результате заказчики и команда получат несомненную пользу от хо­рошо организованного процесса управления требованиями. Кроме того, созданные записи требований будут служить документацией для последователей.