Главная » UML » Элементы технологического процесса и контроль за проектом

0

Рассмотрим рис. 7.3, на котором в форме диаграммы видов деятельности представлена одна итерация технологического процесса управления проектом. Каждый вид деятельности, например открытие нового проекта, — это элемент процесса Rational Unified Process. И наоборот, каждый элемент процесса Rational Unified Process состоит из одного или нескольких видов деятельности. Стоит отметить, что некоторые элементы технологического процесса зависят от времени. Например, открытие нового проекта происходит всего лишь один раз, в начале проекта, а фаза закрытия имеет место только при завершении последней итерации каждой фазы.

Элементы технологического процесса

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

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

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

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

Создание плана разработки программного обеспечения

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

•       Разработка плана измерений

•       Разработка плана управления риском

•       Разработка плана принятия продукта

•       Разработка плана разрешения проблем

•       Определение структуры проекта и обеспечение проекта кадрами

•       Определение процессов наблюдения и контроля

•       Планирование фаз и итераций

•       Составление плана разработки программного обеспечения

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

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

План следующей итерации

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

Наблюдение и контроль над проектом

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

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

•       Непрерывное наблюдение за проектом, включающее наблюдение за активны
ми рисками и объективную оценку прогресса и качества

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

•    Рассмотрение вопросов и проблем по мере их возникновения, а также снятие
их согласно с планом разрешения проблем

 

Управление итерацией

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

Завершение фазы

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

•       Решены ли все основные проблемы предыдущей итерации.

•       Известно ли состояние всех основных артефактов (определяется при ревизии
конфигурации).

•       Рассмотрены   ли   все   проблемы    распространения    (например,   установка,
развертывание, подготовка).

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

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

Завершение проекта

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

Рассмотрим теперь некоторые важные аспекты этих видов деятельности более подробно.

Создание плана фаз

Чтобы начать создание плана фаз, нужно, по меньшей мере, оценить “размер горы”. Например, нужно рассмотреть следующие вопросы.

•       Насколько велика эта гора (т.е. общий объем работ)?

•       Когда нужно добраться до вершины (даты финального выпуска)?

После ответа на эти вопросы можно, исходя из даты выпуска, определить и ориентировочные даты “стоянок” — основных вех.

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

Практика (да и здравый смысл тоже) снова и снова убеждает нас в том, что ускорить выполнение запаздывающего проекта за счет привлечения дополнительного персонала нельзя. Классический пример: “Если женщине требуется девять месяцев на формирование ребенка, то почему девять женщин не могут сделать это за месяц?” Как писал Фред Брукс (Fred Brooks): “Привлечение к запаздывающему проекту дополнительных кадров делает его еще более запаздывающим”. Вообще, в таких случаях можно порекомендовать использование модели затрат, такой как модель СОСОМО (constructive cost model— конструктивная модель затрат), позволяющей проверить справедливость выбранного соотношения между объемом работ, фактической их продолжительностью и уровнем кадрового обеспечения.

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

Резиновый профиль

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

•       Средний размер проекта и средний объем работ

•       Незначительное число рисков и новшеств

•       Находится в первоначальном цикле разработки

•       Не имеет предопределенной архитектуры

116             Часть II. Технологические процессы

Для удобства этот же профиль представлен и в виде таблицы (табл. 7.1). Таблица 7.1. Распределение времени и объема работ по фазам

Фазы                                             Время работы                                  Объем работы

Исследование                               10%                                                     5%

Уточнение плана                          30%                                                     20%

Построение                                   50%                                                     65%

Развертывание                             10%                                                     10%

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

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

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

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

•        Если нужно быстро выпустить продукт на рынок (из-за опоздания или для
захвата рынка) и спланировать постепенное завершение разработки продук
та — уменьшайте фазу построения и увеличивайте фазу развертывания.

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

• В любом случае — проверяйте, не слишком ли много персонала обслуживает проект.

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

Продолжительность итерации

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

 

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

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

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

•       Если мы попытаемся применить этот сценарий для группы из 20 человек, то это
окажется затруднительным. Распределение работы, синхронизация подгрупп и
интеграция будут занимать уже больше времени. В этом случае итерация может
занять три-четыре недели.

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

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

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

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

Таблица 7.2. Длительность итерации, приемлемая для многих итеративных проектов

Количество строк кода               Чис*го сотрудников            Длительность итерации

5 000                                               4                                             2 недели

20000                                            10                                           1 месяц

100 000                                           40                                           3 месяца

1 000 000                                     150                                         8 месяцев

5 При исследовании этого Джо Мараско (Joe Marasko) обратил внимание, что связь продолжительности итерации D (в неделях) с размером проекта S (в тысячах строк кода) выражается формулой д = 1$ , но вы можете относиться к этому как угодно.

 

Количество итераций

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

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

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

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

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

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

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

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

Итак, в фазе уточнения плана требуется от одной до трех итераций.

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

Таким образом, в этой фазе нужны одна-три итерации.

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

Итак, в фазе развертывания нужно провести одну-две итерации.

Окончательно получаем следующее. Существует три уровня проведения полного цикла разработки [И, У, П, Р].

Низкий:         три итерации [О, 1, 1, 1] Типичный:   шесть итераций [1, 2, 2, 1] Высокий:      девять итераций [1, 3, 3, 2]

 

Результат можно подать в общем виде, сказав, что “стандартный” проект имеет 6 ± 3 итерации. Это эмпирическое правило мы будем называть “шесть плюс-минус три”.

По теме:

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