Рамки итерации определяются четырьмя факторами:

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

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

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

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

На этапе уточнения: 

На этапе уточнения цели итерации определяются следующими факторами:

• Риски
• Критичность
• Охват

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

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

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

Примеры

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

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

Пример

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

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

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

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

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

Примеры

1. Создать один профайл подписчика на рабочей станции клиента, сохранить в базе данных сервера вместе с окном пользователя, но не включая все поля и подразумевая, что не обнаружены никакие ошибки.
   Содержит необходимые функции и риски совместимости (базы данных и связного программного обеспечения) и другие аспекты совместимости (работа с двумя разными платформами). Также побуждает разработчиков изучить новый инструмент проектирования графического интерфейса. Создает прототип, который можно будет продемонстрировать пользователю.
2. Убедиться, что можно создать до 20 000 подписчиков и доступ к каждому из них осуществляется не дольше, чем за 200 миллисекунд.
   Касается ключевых требований к производительности (объема или данных и времени ответа), невыполнение которых может серьезно сказаться на архитектуре.
3. Отменить изменение адреса подписчика.
   Простая функция, которая влечет за собой проектирование всех функций отмены. В зависимости от того, какие действия можно будет отменить за разумную цену, пользователи будут выполнять разные операции.
4. Выполнить все варианты использования, связанные с управлением поставками.
   Одна из задач этапа уточнения - завершить фиксацию требований, при необходимости, в нескольких частях.

На этапе построения: 

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

Пример

1. Реализовать все варианты переадресации звонков, включая ошибочные.
   Здесь речь идет о наборе связанных функций. Одна из них, возможно, была реализована на этапе уточнения и в таком случае будет служить прототипом для остальных.
2. Завершить все функции телефонного оператора, кроме услуг в ночное время.
   Еще один набор функций.
3. Обеспечить выполнение 5 000 операций в час в системе из двух компьютеров.
   Повышает требования к производительности, уровень которой в процессе предыдущей итерации достиг только 2 357 операций в час
4. Настроить новую версию географической информационной системы.
   Незначительное изменение архитектуры, вызванное ранее обнаруженной неполадкой.
5. Устранить все неполадки уровней 1 и 2.
   Устраняет неполадки, обнаруженные, не исправленные немедленно и отложенные при тестировании в предыдущей итерации.

На этапе внедрения: 

Основная задача - завершение создания этого поколения продукта. Цели итераций - определить, какие недоработки устранены, какие функции включены для повышения производительности и удобства. Если некоторые функции пришлось опустить или отключить, чтобы выдержать сроки этапа построения (веха IOC или "бета"), сейчас их можно добавить или активировать, если это не представляет угрозы проекту.

Примеры

1. Устранить все неполадки уровня серьезности 1, обнаруженные на пользовательских бета-сайтах.
   Задача, связанная с качеством и влияющая на статус продукта на рынке.
2. Устранить все сбои при запуске, возникающие из-за несоответствия данных.
   Еще одна задача, связанная с качеством.
3. Обеспечить выполнение 2 000 операций в минуту.
   Настройка производительности, требующая оптимизации: изменения структуры данных, кэширования и более точных алгоритмов.
4. Сократить количество различных окон на 30%.
   Задача направлена на повышение удобства использования путем устранения лишних окон на экране.
5. Создать версии на немецком и японском языках.
   Бета-версия была создана только для англоязычных пользователей из-за недостатки времени и необходимости сокращения объема работы.

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

Оценка итераций на начальном этапе

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

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

Оценка итераций на этапе уточнения

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

• Стабильность интерфейса (или надежность)
• Уровень изменений архитектуры (в сравнении с контрольной версией архитектуры)
• Производительность ключевых функций

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

Оценка итераций на этапах построения и внедрения

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

Существуют разные способы поиска ошибок: осмотры и проверки кода, функциональные тесты, тесты на производительность и тесты нагрузки. Каждый метод ориентирован на обнаружение отдельного типа неполадок и используется в определенных ситуациях. Подробное описание этих методов приведено в дисциплине Rational Unified Process Тестирование.

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

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

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

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

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

• Какие классы нужно пересмотреть?
• Какие подсистемы затронуты или созданы?
• Какие интерфейсы может потребоваться изменить?
• Какие документы нужно обновить?

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

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

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

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

• Варианты использования
• Подсистемы
• Классы
• Тесты и планы тестирования
• и другие рабочие продукты.

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