Главная » UML » Типичные планы итераций

0

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

Цель

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

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

•       Итерация в фазе исследования, целью которой является определение видения
проекта и бизнес-плана

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

•       Последняя итерация фазы построения, целью которой является реализация
системы

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

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

Рассмотрим первый пример, приведенный на рис. 16.1, — первую итерацию фазы исследования. Состояние проекта: начало первоначального цикла разработки совершенно новой небольшой системы.

 

Отправная точка. Определение видения системы и области ее действия.

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

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

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

 

Управление проектом. Рассмотрение возможности реализации проекта и описание плана проекта.

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

Управление проектом. Уточнение плана проекта.

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

Результат

Результатом этой итерации являются эскизы видения, бизнес-плана и области действия проекта, а также план проекта. Заинтересованные стороны (организации), инициирующие проект, должны четко представлять себе коэффициент его окупаемости (return of investment — ROI). Иными словами, они должны понимать, что и при каком вложении средств вернется. Исходя из этого принимается решение о судьбе проекта ("принять/ отказаться ").

Проектные графики работ не являются "высеченными на камне". Наоборот, одной из ключевых особенностей Rational Unified Process является то, что первоначальный план проекта– это приблизительная оценка, которая становится реалистичнее по мере развития проекта и разработки реальных метрик, по которым проводится оценка. Лучший способ планирования — это создание проектов по ходу развития. Поэтому всегда стоит обращать внимание на непрерывное усовершенствование плана проекта.

Последующие итерации фазы исследования

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

 

Создание архитектурного прототипа

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

Рис. 16.2. Первая итерация фазы уточнения плана

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

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

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

Архитектор, обсудив с руководителем проекта предварительное прецедентное представление, принимает решение относительно того, на какие прецеденты и сценарии следует обратить внимание в данной итерации; в дальнейшем эти прецеденты

 

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

Управление требованиями. Уточнение направляющих факторов и проверка результатов.

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

Пересмотр прецедентов и рисков.

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

Управление требованиями. Создание прототипа пользовательского интерфейса.

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

Анализ и проектирование. Выделение очевидных классов, предварительное разбиение системы на подсистемы и подробное рассмотрение прецедентов.

Для получения общего представления о классах, которые, очевидно, понадобятся в дальнейшем, архитектор рассматривает системные требования, словарь, прецедентное представление (но не сами прецеденты!) и изучает общие знания команды, относящиеся к данной предметной области. После этого он выполняет предварительное разбиение системы на подсистемы, возможно, с использованием многоуровневой структуры. Также архитектор определяет механизмы анализа, предоставляющие общие решения распространенных проблем, возникающих в процессе анализа. Создается документ архитектуры программного обеспечения (артефакт: документ архитектуры программного обеспечения). Параллельно с этим команда разработчиков, возможно совместно с архитектором, начинает поиск классов или объектов для прецедентов или сценариев данной итерации. Эта команда также распределяет обязанности между определенными классами и механизмами анализа.

 

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

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

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

Для анализа архитектурных служб системы архитектор объединяет некоторые классы в пакеты проекта и соотносит эти пакеты с подсистемами. После этого может понадобиться пересмотр разбиения системы на подсистемы.

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

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

Анализ и проектирование. Рассмотрение параллелизма и распределения архитектуры.

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

Анализ и проектирование. Проверка архитектурного проекта.

Рецензируется архитектура.

Реализация. Рассмотрение физического оформления архитектуры.

Архитектор рассматривает влияние архитектурного проекта на модель реализации и определяет реализационное представление.

 

Реализация. Планирование интеграции.

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

Тестирование. Планирование интегральных и системных испытаний.

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

Реализация. Реализация классов и интеграция.

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

Интеграция реализованных подсистем.

Системные интеграторы последовательно интегрируют подсистемы в выполнимый архитектурный прототип. Тестируется каждая конструкция.

Тестирование. Оценка выполнимой архитектуры.

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

Оценка собственно итерации.

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

Результат

Результатом этой итерации является предварительный эскиз архитектуры. Он состоит из достаточно хорошо описанных архитектурных представлений (прецедентное, логическое и реализационное представления) и выполнимого архитектурного прототипа.

 

Последующие итерации фазы уточнения плана

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

Реализация системы

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

Управление проектом. Планирование итерации.

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

Реализация. Планирование интеграции на системном уровне.

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

 

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

Тестирование. Планирование и проектирование тестирования на системном уровне.

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

Анализ и проектирование. Уточнение реализаций прецедентов.

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

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

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

Реализация. Разработка кода и тестирование блоков.

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

Реализация. Планирование и реализация блочных испытаний.

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

 

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

Реализация. Тестирование блоков в подсистеме.

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

Реализация и тестирование. Интеграция подсистемы.

Целью интеграции подсистемы является объединение в выполнимую конструкцию блоков, которые могут поступать в подсистему от различных разработчиков. Конструктор, в соответствии с планом, интегрирует подсистему путем объединения завершенных и суррогатных классов, составляющих конструкцию. Интеграция подсистемы ведется по возрастающей — от минимальных блоков до более крупных (при этом используются иерархические зависимости этих блоков).

Реализация. Тестирование подсистемы.

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

Реализация. Выпуск подсистемы.

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

Реализация. Интеграция системы.

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

Тестирование. Тестирование интеграции.

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

 

Тестирование. Тестирование системы.

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

Управление проектом. Оценка собственно итерации.

Руководитель проекта сравнивает действительные стоимость итерации и график работ с соответствующими пунктами плана итерации; определяет, необходима ли доработка или переработка, и, если необходимы, назначает их на последующие итерации; обновляются перечень рисков (артефакт: перечень рисков) и план проекта (артефакт: план проекта); подготавливается эскиз плана итерации для следующей итерации (артефакт: план итерации).

Результат

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

Резюме

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

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

 

По теме:

  • Комментарии