Глава 3. Планирование процесса

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


3.1. Процесс разработки в InfoSys 
Менеджеру нужно решить, какой процесс должен использоваться для создания ПО из:

1. Каскадная модель
2. Итеративная
3. Создание прототипов
4. Спиральная.

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


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

1. Анализ требований
2. Высокоуровневое проектирование
3. Детальное проектирование
4. Создание элементов
5. Тестирование элементов
6. Планирование сборки
7. Сборка
8. Планирование системного тестирования
9. Системное тестирование
10. Документирование
11. Приемка
12. Установка
13. Гарантийное обслуживание.

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


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

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

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


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

Значения	Суммарные инструкции	Зачем?
Численность команды >=5, продолжительность <3 месяцев, низкая понятность требований, новая технология, опытный лидер проекта	Связанные с разработкой графика работ
	Создать план для мини-этапов	Позволяет быстро выявлять проблемы и улучшает контроль над проектом. Число рисков, связанных с разработкой графика, уменьшается, поскольку представления на графике становятся более частыми. Больше возможности контролировать снижение трудоемкости в начале проекта.
	Постараться ограничить поставки временными рамками	Потенциально сокращает сроки, поскольку обеспечивает поставку системы через фиксированные интервалы и препятствует изменению ее характеристик. Сокращается количество рисков, связанных со сроками
	Связанные с трудоемкостью
	Применять соответствующие факторы регулирования к базовой оценке, как определено в инструкциях по оцениванию	Все ограничения проекта учитываются при оценке трудоемкости, что позволяет спрогнозировать реалистичную временную шкалу
	Дать оптимистическую, пессимистическую и вероятностную оценки	Сокращает риски, связанные с ошибочной оценкой и "быстрыми" обязательствами
	Пересмотреть и заново согласовать оценки в конце стадии проектирования
	Связанные с выделением человеческих ресурсов
	Назначить квалифицированных исполнителей для всех задач	Улучшает продуктивность Риски, связанные со сроками, уменьшатся
	Получить помощь экспертов по вопросам, связанным с производительностью	Минимизируются переработки и задержки, определяемые настройкой производительности
	Связанные с формализмом
	Определить все заинтересованные стороны, их цели и присвоить им приоритеты	Помогает сосредоточиться на ясных целях. Сокращает риски, связанные со сторонами, поскольку важные факторы успеха определены, согласованы и учтены в работе
	Регулярно сообщать старшему руководству о ходе действий по снижению рисков	Риски, связанные со сроками, снижаются активными действиями в этом направлении
	Определить формальный процесс управления изменениями требований и добиваться от команды его строгого соблюдения	Снижает до минимума влияние изменений требований на график работ

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

3.2. Управление изменениями требований 
Требования могут возникнуть в любой момент на протяжении жизни проекта, иногда даже после закрытия. Чем позже меняются требования, тем больше влияние это оказывает на проект. При выполнении проекта нужно сразу же настроиться на то, что требования будут изменяться. Изменения в требованиях могут составлять до 40% общей стоимости проекта. Процесс управления изменениями требованиями определяет набор действий, которые выполняются при возникновении новых требований или изменений существующих. Менеджеры проектов регулярно пользуются этим процессом как средством, позволяющим пояснить процесс заказчикам и обеспечить выполнение ими обязательств по заказу. 


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

1. Регистрация изменений.
2. Анализ их влияния на рабочие продукты.
3. Оценка трудоемкости, необходимой для выполнения заявок на изменения
4. Повторная оценка графика поставки
5. Анализ влияния на накопленную стоимость
6. Обсуждение этого влияния с вышестоящим руководством, если превышены пороговые значения.
7. Получение подтверждения изменения от заказчика
8. Исправление рабочих продуктов

Для отслеживания заявок на изменения ведется специальный журнал. Каждая запись в журнале состоит из

• номера заявки,
• Краткого описания изменения
• Состояния заявки на изменение
• Основные даты.

Эффект изменения оценивается путем анализа его влияния, который включает:

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

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


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

Заявка №: 3 Дата: 11 августа 2000г.

Спецификация изменения

Эта заявка на изменение должна позволить клиентским экранам автоматически изменять разрешение в зависимости от монитора. Это необходимо, поскольку мониторы заказчика имеют разрешение 1600*1200, в то время, как мониторы бизнес-партнера, который также будет пользоваться этим приложением, имеют разрешение 800*600.

Анализ влияния

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

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

Влияние на трудоемкость: общее количество экранов равно 40. Реализация решения для экрана потребует приблизительно 12 часов. Следовательно, общая трудоемкость реализации этого изменения составит 480 человеко-часов (53 человеко-дней).

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

Состояние:

Анализ утвержден заказчиком. Заявка будет учтена немедленно. Будет изменен график выполнения работ по проекту. Также изменяться сроки выполнения этапов там, где это необходимо.

Подготовил: XXXXXXXXX Рассмотрел: ХХХХХХХХХХХХ

Пример заявки на незначительное изменение

Проект XYZ

Запрос № 11 Дата 23 февраля 1998 г.

Спецификация изменения: 12/02 Analyser для CDMA

Анализ влияния

Никаких изменений в модуле конфигурирования и анализаторах для CDMA не требуется. (Дальше - подробное описание изменений)

Влияние на график работ: нет

Влияние на трудоемкость: 5

Состояние: будет включено в новый пакет CDMA

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

Номер заявки на изменение	Дата заявки на изменение	Спецификация изменения	Трудоемкость (человеко-дней)	Состояние
1	18.02.2001	Определяет статистику использования	3	Закрыта 23.02.2001
2	На демонстрации	Блокировка пользователей	2	Открыта
…	…	…	…	…
		Итого	51

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

3.3. Планирование процесса для проекта АСИС 
Поскольку проект АСИС - это процесс разработки, то соблюдается стандартный процесс разработки. Однако в соответствии с пожеланиями заказчика он адаптирован к требованиям методологии Rational Unified Process (RUP). RUP устанавливает итеративный подход к разработке. Инструкции адаптации позволяют итеративно выполнять различные фазы, поэтому спецификация, проектирование, программирование и тестирование проводятся на каждой итерации. Кроме итеративной разработки, введенной, чтобы привести стандартный процесс в соответствие с требованиями RUP, в нем так же были сделаны следующие модификации:

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

Кроме того, стандартный механизм матрицы трассировки не будет использовать для трассировки требований. Требования будут отслеживаться с помощью Requisite Pro, входящего в среду разработки. Для управления изменениями используется стандартный процесс. Хотя анализ влияния выполняется для каждой заявки, повторное оценивание будет проводиться, только если ожидается, что заявка потребует более 2% общей трудоемкости. Результаты планирования фиксируются в плане управления проектом.

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

• Планируя процесс для проекта, начинайте со стандартного процесса. Подходящей основой может послужить каскадная модель, разбитая на небольшие фазы.
• Определяя оптимальные процесс для проекта, адаптируйте к его ограничениям стандартный процесс. Сначала установите контекст адаптации, используя основные характеристики проекта. Затем выполните детальную адаптацию действий. В этом могут помочь инструкции по адаптации
• Создайте отдельный процесс управления изменениями требований, который будет оценивать влияние каждой заявки на изменение и отслеживать совокупное влияние всех заявок. По отношению к СММ описанные в этой главе методы планирования процесса удовлетворяют некоторым требованиям KPA планирования программного проекта уровня 2. Подход с использованием адаптации удовлетворяет некоторым требованиям КРА интегрального управления разработкой ПО на уровне 3. Метод управления изменениями требований соответствует некоторым требованиям КРА управления уровня 2.