Главная » UML » Создание плана итерации

0

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

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

План итерации подробно описывает, что должно произойти за время итерации. Он распределяет виды деятельности исполнителям и назначает сотрудников на роль исполнителей. (Напомним, что термин исполнитель используется нами в несколько особом смысле; см. главу 3.) Для обработки подробностей плана полезно применять инструментальные средства, такие как Microsoft Project; в частности, это удобно при определении зависимостей и распределении заданий сотрудникам.

Для создания плана итерации следует пройти четыре этапа.

1.          Определить объективные критерии успеха итерации. Эти критерии будут ис
пользоваться в конце итерации (при ее оценке) и позволят определить, успеш
ной или неудачной была итерация.

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

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

4.          Использовать смету при определении продолжительности и объема работ для каж
дого вида деятельности, удерживая все значения в пределах бюджета ресурсов.

А теперь, как и обещали ранее, рассмотрим изменения схемы итерации в зависимости от фазы.

Итерация в фазе уточнения плана

Существует три основных фактора, определяющих цели итерации в фазе уточнения плана.

•       Риск

•       Охват

•       Критичность

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

 

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

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

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

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

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

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

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

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

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

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

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

 

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

Приведем несколько примеров целей итераций.

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

2.           Обеспечить возможность поддержки до 20 000 абонентов; время доступа к отдельному
абоненту не должно превышать 200 миллисекунд.
Данный сценарий связан с ключе
выми аспектами производительности (объемом информации и временем от
клика), несоответствие которым может оказать значительное влияние на архи
тектуру.

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

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

Итерация в фазе построения

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

Приведем примеры целей итераций для фазы построения.

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

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

3.     Добиться выполнения 5 000 операций в час с помощью схемы из двух компьютеров. Це
лью может быть увеличение производительности, полученной в ходе предыду
щей итерации (например, всего 2 357 операций/час).

4.      

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

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

Итерация в фазе развертывания

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

Приведем примеры целей итераций фазы развертывания.

1.         Решить все первостепенные проблемы,  обнаруженные при проведении бета-тестиро
вания.
Данная цель относится к улучшению качества и может быть связана с за
воеванием рынка.

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

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

4.    Снизить число различных диалоговых окон на 30%. Повышение удобства использо
вания путем снижения нагрузки на зрение.

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

Подробнее о работе при итерации

Теперь, когда объективно определено, что же ожидается от итерации, можно приступать к этапу подробного планирования.

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

•       Какие классы должны быть переработаны?

•       Какие подсистемы затрагиваются или создаются?

•       Какие интерфейсы могут требовать модификации?

•       Какие документы следует обновить?

Следующим этапом является определение видов деятельности Rational Unified Proc- ! ess, которые будут задействованы в итерации, и внесение их в план проекта. Некоторые | действия производятся один раз за итерацию (например, создание плана итерации), другие же должны  выполняться для  каждого  класса,  прецедента или  подсистемы j

 

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

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

Резюме

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

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

•       Основным фактором, направляющим планирование, является риск.

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

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

•       Критерии, определяющие масштаб итераций, меняются в зависимости от фазы
проекта.

•        

По теме:

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