Фаза Начало Первая итерация
В фазе Начало принимают участие в основном только Менеджер проекта, Архитектор и Системный Аналитик. Во второй итерации фазы Начало к ним присоединяются Спецификатор ВИ и Аналитик ВИ (см. рис. 4), но объём их работы невелик.
рис. 4 Распределение ролей по итерациям фазы Начало
На первой итерации фазы Начало происходят следующие действия:
Системный аналитик выполняет следующие задачи (см. рис 5):
рис. 5 Задачи системного аналитика на первой итерации фазы Начало.
Системный аналитик начинает пытаться определить основную суть будущей системы – это, прежде всего, её цель (т.е. проблемы и задачи, которые она призвана решить). Для этого он определяет всех заинтересованных лиц проекта (абсолютно всех – от непосредственного заказчика и конечных пользователей до менеджеров по продажам будущей системы) и начинает собирать воедино все требования, которым система должна удовлетворять.
Немного определившись с требованиями, системный аналитик начинает работу по нахождению актёров будущей системы и основных вариантов использования. К концу первой итерации должны быть найдены только основные, критические варианты использования, которые, как показывает практика, составляют около 5-10% от общего числа вариантов использования.
Параллельно с общением с заинтересованными лицами и с выделением вариантов использования начинает создаваться глоссарий – список специфических терминов будущей системы и, при необходимости, предметной области.
Менеджер проекта выполняет следующие задачи (см. рис 6):
рис. 6 Задачи менеджера на первой итерации фазы Начало.
Прежде всего, менеджер создаёт планы на все случаи жизни: планы итераций, фаз и собственно проекта. Поначалу они могут быть очень приблизительными, но на данном этапе это не критично.
Затем менеджер начинает выявлять риски, с которыми может столкнуться проект. Основным исполнителем этого артефакта является менеджер, но фактически его создаёт и архитектор (в разделе «Технические риски»). Менеджер отвечает за всевозможные организационные риски и за компиляцию всех идентифицированных рисков в один документ.
Основной же задачей менеджера на данном этапе является создание концепции – высокоуровневого видения системы. Оно должно включать в себя основную цель системы – т.е. то, какие проблемы оно решает и какие выгоды приносит пользователям, основные функциональные и нефункциональные требования. Подобно списку рисков, этот артефакт создаётся не только менеджером, но при участии системного аналитика и архитектора.
Список рисков и первые приближения концепции уже на данном этапе могут дать ответ на главный вопрос первой фазы – начинать ли команде разрабатывать данный проект или нет.
Архитектор на первой итерации первой фазы начинает формировать широкое, но неглубокое описание системы. В результате выполнения задач «Анализировать архитектуру» и «Проектировать архитектуру» он получает первые наброски моделей проектирования, реализации и развёртывания. (см. рис 7)
рис. 7 Задачи архитектора на первой итерации фазы Начало.
Основная цель этой итерации – по возможности максимально узнать основную информацию о новом проекте, о том, как его видит заказчик.
Вторая итерация
Менеджер команды продолжает выполнять все те же действия, что и на первой итерации, он развивает и углубляет те же артефакты (см. рис 8). Плюс, у него появляется одна специфическая для нашего процесса задача – создать пакет документов для сдачи фазы Начало. Суть этой задачи – не просто скомпилировать все документы воедино, а убедиться, что все они созданы и развиты на достаточном для данной фазы уровне.
рис. 8 Задачи менеджера на второй итерации фазы Начало.
Цель всех действий менеджера на данной фазе – принять решение, заниматься ли разработкой этого проекта вообще, и если да, то на каких условиях.
Основной деятельностью системного аналитика является создание и развитие модели вариантов использования, для чего он выполняет задачу «Структурировать модель ВИ». (см. рис 9)
Рис. 9 Задачи системного аналитика на второй итерации фазы Начало
Цель всех действий аналитика на фазе начало – понять, зафиксировать и достичь соглашения со всеми заинтересованными сторонами относительно того, что будет делать будущая система. Если аналитику не удалось с достаточной долей ясности понять основную функциональность системы, или не было достигнуто соглашение со всеми заинтересованными лицами, то переход к новой фазе будет серьёзным функциональным и организационным риском. В таком случае менеджеру команды необходимо будет принимать решение – или продлевать фазу Начало ещё на одну итерацию, или отказываться от дальнейшей разработки данного проекта.
Архитектор продолжает развитие созданных ранее моделей (проектирования, реализации, развёртывания). Обязательной задачей является упорядочивание вариантов использования по приоритетам. Эта задача выполняется совместно с аналитиком (который представляет интересы заказчика) и её цель – определить среди всех вариантов использования архитектурно значимые, т.е. те, реализация которых должна обязательно войти в архитектуру системы. (см. рис 10)
Не обязательным, но очень желательным и полезным (прежде всего, для команды разработчиков) является создание базового уровня архитектуры – это одно из возможных решений реализации архитектурно-значимых вариантов использования. БУА может быть очень концептуальным, но уже сам факт его создания означает, что задача, поставленная перед командой разработчиков, имеет как минимум одно решение.
рис. 10 Задачи системного аналитика на второй итерации фазы Начало
Плюс к разработке БУА архитектор может разработать ещё один вид прототипа системы - не эволюционный (коим является базовый уровень архитектуры), а т.н. «выбрасываемый», который служит только одной цели и «выбрасывается» сразу после того, как результаты были получены. На данном этапе имеет смысл построения исследовательского и поведенческого прототипов. Исследовательский прототип создаётся для того, чтобы проверить самые основные допущения проекта касательно функциональности, технологии, или и того, и другого. Поведенческий же может не реализовывать никакой функциональности, а только давать представление о поведении системы. Поведенческие прототипы очень эффективны при анализе и проектировании сетевых приложений, особенно тех, в которых используются транзакции, где больше всего используются окна диалога с системой.
Таким образом, построение небольшого прототипа при минимуме затрат может принести проекту существенную пользу.
Цель всех действий архитектора на данной фазе – определить, как будет реализовываться будущая система.
Спецификатор вариантов использования начинает работу по описанию ВИ. (см. рис. 11)
рис. 11 Задачи спецификатора вариантов использования на второй итерации фазы Начало
К концу первой фазы разработки должно быть описано порядка 10% от общего числа ВИ системы.
Анализатор ВИ анализирует описанные спецификатором ВИ. (см. рис 12)
рис. 12 Задачи анализатора вариантов использования на второй итерации фазы Начало
К концу первой фазы разработки должно быть проанализировано порядка 5% от общего числа ВИ системы.
Взаимодействие аналитик-спецификатор-анализатор наглядно демонстрирует один из основных принципов унифицированного процесса – трассируемость элементов. Трассируемость означает, что артефакты, полученные как результат на предыдущем этапе деятельности, служат входными данными на последующих этапах и обеспечивают логическую связь между этапами. В приведённом примере запросы заинтересованных сторон трассируются в варианты использования, затем они получают формальное описание и превращаются в модель анализа (в виде диаграмм взаимодействия или последовательности).
Вот краткий список всех артефактов, созданных в результате прохождения командой фазы Начало (см. рис. 13):
рис. 13 Список артефактов, полученных в результате фазы Начало.
|
