Что такое начальная фаза

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

Для большинства проектов необходим небольшой начальный этап, на котором нужно сформулировать ответы на следующие вопросы:

• Каково ваше видение проекта?

• Реально ли осуществить задуманное?

• Что лучше: купить или разработать?

• В какую сумму (примерно) обойдется реализация проекта: 10-100 тысяч или миллионы долларов?

• Стоит ли браться за этот проект?

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

На этом этапе необходимо лишь осмыслить общие задачи проекта и его реалистичность, а также сформировать объективное мнение о целесообразности продолжения проекта (более глубокое изучение будет выполнено на стадии развития).

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

Полезная аналогия: когда в нефтяной промышленности принимается решение о начале разработки нового месторождения, выполняются следующие действия:

1. Определяется, достаточно ли информации и аргументов для обоснования необходимости бурения пробной скважины.

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

3. Оценивается нефтяной запас и целесообразность затрат на разработку.

4. Начинается разработка.

Начальная фаза разработки программного продукта соответствует первому этапу в этой аналогии, когда специалисты еще не знают, каков нефтяной запас в данном регионе или какой будет стоимость его разработки. Для подобных выводов еще недостаточно информации. Конечно, очень заманчиво сразу ответить на все вопросы “сколько” и “когда”, не приступая к исследованию проблемы, но нефтяники понимают, что это нереально. В терминах Unified Process (UP) реальное исследование проблемы выполняется на стадии развития. Начальная фаза сродни анализу достижимости, на этой стадии требуется принять решение о целесообразности капиталовложений в бурение пробной скважины.

Оределение требований

Требования (requirements) — это возможности или условия, которым должна соответствовать система или проект.

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

Как требования связаны с артефактами UP

В UP предусмотрены несколько артефактов, связанных с требованиями. Как и все артефакты UP, они являются необязательными. К основным из них относятся следующие.

• Модель прецедентов (Use-Case Model). Набор типичных сценариев использования системы. Эта модель предназначена в основном для определения функциональных требований или требований, связанных с поведением.

• Дополнительная спецификация (Supplementary Specification). Включает в основном требования, не определяемые прецедентами. Этот артефакт предназначен для формулировки нефункциональных требований, например, связанных с производительностью или лицензированием. Здесь же могут быть описаны функциональные свойства (feature), не представленные в описании прецедентов, например, связанные с генерацией отчетов.

• Словарь терминов (glossary). В простейшем случае в этом словаре определяются важные термины. Зачастую он также служит словарем данных (data dictionary), в котором описываются требования, связанные с данными, например, правила верификации, допустимые значения и т.д. В словаре можно детализировать любой элемент: описание атрибута объекта, параметры вызова операции, макет отчета и т.д.

• Видение (vision). В этом документе подытоживаются высокоуровневые требования, освещенные в модели прецедентов и дополнительной спецификации. Это краткий обзорный документ для быстрого ознакомления с главными идеями проекта.

• Бизнес-правила (business rule). Обычно бизнес-правила (или правила предметной области) описывают требования или политики, выходящие за пределы конкретного программного проекта. Эти правила работают в определенной предметной области, и им должны удовлетворять многие приложения. Прекрасным примером являются государственные нормы налогообложения. Эти правила могут быть детально представлены в дополнительной спецификации. Но поскольку они применимы не только в данном конкретном проекте, их целесообразно поместить в главном артефакте, описывающем бизнес-правила и используемом всеми аналитиками компании. Это облегчит их повторное использование в других проектах.

Определение прецедентов (вариантов использования)

Необходимый первый шаг для достижения заветной цели — понять, чего же вы хотите.
Бен Штайн (Ben Stein)

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

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

Описание прецедентов (вариантов использования)

Исполнителем (actor) называется сущность, обладающая поведением, например, человек (идентифицируемый по роли, к примеру, кассира), компьютерная система или организация. Сценарий (scenario) — это специальная последовательность действий или взаимодействий между исполнителями и системой. Его иногда также называют экземпляром прецедента (use case instance). Это один конкретный сценарий использования системы либо один проход прецедента, например, сценарий успешной покупки товаров за наличный расчет либо сценарий неудачного завершения покупки из-за прерванной транзакции по обработке данных кредитной карточки.

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

В контексте UP модель прецедентов (Use Case Model) относится к дисциплине “Требования”. Действительно, требования — это весь набор прецедентов, т.е. модель функционирования системы и ее окружения.

Описания прецедентов — это текстовые документы, а не диаграммы. Моделирование прецедентов — это процесс написания текста, а не рисования.

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

Зачем нужны описания прецедентов

У потребителей и конечных пользователей есть свои задачи, решение которых должна обеспечить компьютерная система. Эти задачи могут варьироваться от регистрации торговых операций до оценивания объемов добычи нефти из перспективных месторождений. Существует несколько способов выделения этих задач или системных требований. Наилучшие из них достаточно просты и доступны, поскольку это облегчает участие конечных пользователей в определении требований к системе. А участие в этом процессе потребителей снижает риск провала проекта. Эти рассуждения могут показаться очевидными, но они очень важны. Одной из главных причин провала проектов по разработке программных систем является недостаточное привлечение пользователей к процессу разработки. Поэтому важность участия пользователей в процессе анализа системы трудно переоценить.

Прецеденты — это механизм упрощения этапа формулировки требований для всех заинтересованных лиц.

Ориентация на цели и задачи пользователя

Важной особенностью описания прецедентов является их ориентация на цели и задачи пользователя. В процессе описания необходимо задавать вопросы: “Кто является пользователем системы? Каковы типичные сценарии использования системы? Каковы цели и задачи пользователей?”. Такой взгляд на систему гораздо больше ориентирован на пользователя, чем обычный список системных требований. Зачастую прецеденты нужно продумывать гораздо детальнее. Но основная идея состоит в исследовании и формулировке функциональных требований путем написания историй “из жизни системы”. Эти истории помогают сформулировать различные задачи и представляют собой сценарии использования системы. На первый взгляд, описать прецеденты не сложно, хотя зачастую достаточно трудно определить, что требуется от системы и описать это на нужном уровне детализации.

Исследование целей, а не обязанностей и процедур, позволяет сосредоточить внимание на основных требованиях. Например, на одном из семинаров кассир может сказать, что одной из его целей является регистрация в системе. При этом он может иметь в виду элементы интерфейса пользователя, соответствующие диалоговые окна, ввод идентификатора и пароля. Однако все это — механизмы достижения цели, а не сама цель. Изучая иерархию целей (отвечая на вопрос “какова цель этой задачи?”), системный аналитик приходит к формулировке, независимой от механизма реализации: “идентифицировать себя и выполнить аутентификацию” или на более высоком уровне — “предотвратить утечку информации”.

«Что», а не «как»

Описание прецедента в формате “черный ящик” (black-box use cases) — это самый типичный и рекомендуемый тип описания прецедентов. Они не описывают внутреннюю работу системы, ее компоненты или дизайн. Наоборот, системе вменяются некоторые обязанности (responsibilities). Этот метафорический термин широко применяется в объектно-ориентированном проектировании: программные элементы имеют обязанности и взаимодействуют с другими элементами со своими обязанностями. Определяя обязанности системы через прецеденты типа “черный ящик”, можно указать, что должна делать система (функциональные требования), не расписывая, как это делать (не выполняя проектирование). Вообще, термины “анализ” и “проектирование” зачастую сводятся к вопросам “что” и “как”. Это важные вопросы в хорошей программной разработке. В процессе анализа требований нужно избегать принятия решений “как”, а описывать лишь внешнее поведение системы как черного ящика. Позднее, на этапе проектирования, создается решение, удовлетворяющее разработанной спецификации.

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

Исполнители имеют свои задачи (или потребности), для решения которых они используют систему. Поэтому при описании прецедентов необходимо идентифицировать исполнителей и их задачи, которые должны быть решены в результате создания системы. При таком подходе несколько смещаются акценты аналитиков. Вместо вопроса “Каковы задачи системы?” возникает вопрос “Кто является исполнителем и каковы их задачи?”. Чтобы отобразить эту взаимосвязь, имя прецедента должно соответствовать названию задачи. Например, задаче электронного оформления продажи должен соответствовать прецедент "Оформление продажи". Таким образом, ключевая идея состоит в том, чтобы для выделения прецедентов исследовать задачи исполнителей.

Элементарный бизнес-процесс

Термин элементарный бизнес-процесс (EBP — Elementary Business Processes) заимствован из области исследования бизнес-процессов и определяется следующим образом.

“Элементарный бизнес-процесс — это задача, выполняемая одним человеком в одном месте в одно время в ответ на некоторое бизнес-событие, добавляющая измеряемое бизнес-значение и переводящая данные в некоторое устойчивое состояние, например, подтверждение платежа по кредитной карточке или распоряжение брокеру при изменении цен”.

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

Это определение не следует воспринимать слишком буквально. Могут ли в сценарии прецедента участвовать два человека? Скорее всего, да. Однако общая идея этого определения верна. Прецедент — это не один маленький шаг, такой, например, как удаление товара или печать документа. Основной сценарий прецедента обычно включает пять-десять шагов. Описываемый сценарий выполняется не в течение нескольких дней или сеансов, как, например, переговоры с поставщиками. Это задача, выполняемая в течение одного сеанса. Реализация прецедента может длиться от нескольких минут до нескольких дней. Как и при определении унифицированного процесса, основное внимание уделяется получению ощутимого (измеримого) результата и переходу системы и данных в устойчивое состояние.

Диаграммы прецедентов (вариантов использования) как изображение системного контекста

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

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

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

Дополнительная спецификация

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

Например,

Список свойств системы

• Регистрация продаж.

• Авторизация платежей (кредитных, дебетных, чековых).

• Системное администрирование для управления пользователями, безопасностью, таблицами кодов и констант и т.п.

• ...

Когда применять моделирование прецедентов

Иногда прецедентов недостаточно. Для некоторых систем нужно разработать детальный список свойств. Например, серверы приложений, системы управления базами данных и другие базовые системы нужно рассматривать в терминах свойств (“В следующей версии необходима поддержка Web-служб”). Прецеденты не годятся для разработки таких приложений.

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

Прецеденты являются лучшим выбором для фиксирования требований в тех случаях, когда:

• в системе преобладают функциональные требования;

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

• в системе много интерфейсов (много акторов).

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

Диаграммы деятельности (activity diagrams) в дисциплине бизнес-моделирования

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

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

Одной из дисциплин UP является бизнес-моделирование. Ее задача — сформировать и отразить “структуру и динамику организации, в которой развертывается система”. Основным артефактом этой дисциплины является модель бизнес-объектов (прототип модели предметной области UP), в рамках которой с помощью диаграмм классов, последовательностей и деятельности UML обычно отображается экономическая деятельность предприятия. Таким образом, диаграммы деятельности чаще всего строятся в процессе дисциплины бизнес-моделирования.

Прецеденты в рамках итеративной разработки

Прецеденты играют жизненно важную роль при реализации унифицированного процесса и многих других итеративных методов,  поскольку вся разработка в рамках этого подхода  осуществляется под управлением прецедентов  (use case  driven development). Это означает следующее:

• Функциональные требования в основном формулируются при описании прецедентов (в модели прецедентов). Остальные требования (если таковые существуют) являются либо техническими (например, список функций), либо второстепенными.

• Прецеденты - важный этап итеративного планирования. На каждой итерации реализуются некоторые сценарии или целые прецеденты. Поэтому описания прецедентов вносят существенный вклад в оценивание результата.

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

• Описание прецедентов зачастую отражается на организации руководства пользователей.

• Функциональное и системное тестирование соответствует сценариям прецедентов.

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

Другие артефакты требований

Прецеденты не являются исчерпывающим описанием системы.

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

В словарь терминов (glossary) включаются термины и определения. Он также может служить словарем данных.

Документ “Видение” (Vision) определяет видение проекта. Он описывает важнейшие идеи, положенные в основу разработки системы.

Бизнес-правила (business rule) — это устойчивые правила или политики, применяемые в предметной области, например правила налогообложения.

Помимо прецедентов, функции системы можно выразить через ее свойства, а точнее системные свойства (system features), представляющие собой высокоуровневые, краткие утверждения, описывающие функции системы. Более строго в контексте UP системное свойство определяется как “наблюдаемая извне и обеспечиваемая системой функция, которая напрямую удовлетворяет потребности заинтересованного лица”.

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

В документе “Видение” системные свойства вкратце отражают функциональные требования, которые более детально изложены в описании прецедентов. В этом документе можно также отразить другие требования (например, к надежности и удобству в использовании), которые более подробно описаны в разделе “Специальные требования” модели прецедентов и в дополнительной спецификации.

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

Различные артефакты, относящиеся к требованиям, создаются параллельно. Тем не менее, можно порекомендовать такую последовательность разработки:

1. Краткий черновой вариант документа “Видение”.

2. Идентификация задачи пользователей и соответствующих прецедентов.

3. Описание некоторых прецедентов и начало разработки дополнительной спецификации.

4. На основе полученной информации уточнение документа “Видение”.

Словарь терминов (глоссарий)

Словарь терминов (glossary) представляет собой список важных понятий и их определение. Очень часто возникает ситуация, когда технический или другой термин используется заинтересованными лицами в несколько различных значениях. Такие противоречия необходимо разрешить для облегчения общения и однозначной формулировки требований.

В рамках UP словарь терминов также играет роль словаря данных (data dictionary) — документа, содержащего информацию о данных, т.е. метаданные (metadata). На начальной стадии проекта словарь терминов включает лишь основные термины и их описание, а на стадии развития его можно превратить в словарь данных.

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

Глоссарий проекта предоставляет определения ключевых бизнес-терминов, включает синонимы и омонимы.

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