Глава 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.

Глава 2. Инфраструктура планирования проекта

Конспект Pankaj Jalote "Управление программным продуктом на практике"

Как создать память организации и на основе ее - инфраструктуру для планирования проектов? Какими должны быть элементы этой структуры, как должна систематически фиксировать накопленный опыт и как сделать его для повторного использования. Как поддерживать такую инфраструктуру в рабочем состоянии. В базе данных процессов (process database, PDB) фиксируются данные о производительности в завершенных проектах. Базовая линия устойчивости процесса (process capability baseline, PCB) суммирует производительность по всем проектам, т.е. она количественно определяет диапазон результатов, полученных при соблюдении процессов. Имущество процессов (активы процессов ?) - это такие документы, как контрольные перечни, шаблоны, методологии и полученные уроки, т.е. материалы, фиксирующие накопленный опыт и помогающие менеджерам проектов и инженерам эффективно пользоваться процессами. 2.1. База данных процессов Представляет собой постоянное хранилище данных о производительности процессов из проектов, которые могут использоваться для планирования и оценки проекта, анализа продуктивности и качества, а также в других целях. Состоит из данных, полученных в завешенных проектах, и каждый проект предоставляет одну запись данных. Для этого необходимо собрать данные, проанализировать их, а затем сформировать запись в базе данных. 2.1.1. Содержимое базы данных процессов Аналогичные проекты - в PDB необходимо зафиксировать общую информацию о проекте:

• Предметная область
• Языки программирования
• Платформы
• Базы данных
• Инструменты
• Размер ПО
• Трудоемкость. В том числе с распределением по фазам
• Ошибки
• Графики работ
• Риски
• Прочее

Таким образом, данные можно классифицировать:

• Характеристики проекта
  • Название проекта
  • Имена, контакты менеджеров проекта и лидеров модулей
  • Подразделение (для анализа по подразделениям)
  • Размещенный процесс (анализ процессов по отдельности)
  • Предметная область
  • Аппаратная платформа
  • информация о его рисках
  • продолжительность выполнения
  • Численность команды
• График работ по проекту
  • Плановые даты
  • Фактические даты
• Трудоемкость проекта
  • Первоначальная оценка трудоемкости
  • Общая фактическая трудоемкость
  • Распределение фактической трудоемкости по стадиям проекта
• Размер ПО
  • Число строк кода (LOC)
  • Количество простых, средних и сложных программ или сочетание этих показателей - Число функциональных точек (FP).
  • Размер окончательной системы в FP.
• Ошибки
  • Число ошибок, найденных разными методами их обнаружения
  • Число ошибок, внесенных на разных стадиях
    • При экспертизе требований
    • Экспертизе кода
    • Тестировании элементов
    • …
  Необходимо фиксировать число обнаруженных ошибок и для стадий внесения, и для стадий обнаружения. Стадии обнаружения - это разнообразные экспертизы и тестирование; стадии внесения - это анализ требований, проектирование и программирование.
  • Замечания
    • По оцениванию
    • По управлению рисками

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

• Качество поставленного продукта
• Продуктивность
• График работ
• Распределение трудоемкости
• Темп внесения ошибок
• Внутренняя эффективность устранения ошибок процесса
• Стоимость качества
• Распределение ошибок

Поскольку базовая линия показывает устойчивость процесса, необходимо создать отдельные базовые линии для каждого процесса в организации. Например, для проектов сопровождения, реинжиниринга и разработки. Для однотипных проектов необходимо создать свою PCB. 2.3. Имущество процесса и система совокупности знаний Имущество процесса (process actives) - инструкции, контрольные перечни, шаблоны. Инструкции обычно устанавливают правила и процедуры выполнения шага. Контрольный перечень действий - список действий, составляющих шаг процесса. Цель перечня экспертизы - привлечь внимание экспертов к ошибкам, которые с большой вероятностью могут обнаружиться в конечном продукте. Шаблоны обычно предоставляют структуру документа, в котором можно зафиксировать результаты процесса или шага. Все инструкции, контрольные перечни и шаблоны доступны в оперативном режиме и регулярно обновляться.

Инструкции	Контрольные перечни	Шаблоны/Формы
Инструкции по оценке трудоемкости и графика работ	Контрольный перечень анализа требований	Документ спецификации требований
Процедура групповой экспертизы	Контрольные перечни плана тестирования элементов и тестирования системы	Документ плана тестирования элементов
Инструкции по адаптации процесса	Контрольный перечень управления конфигурацией	Документ плана приемочных испытаний
Инструкция по адаптации процесса	Контрольный перечень управления конфигурацией	Документ плана приемочных испытаний
Инструкция по оценке и мониторингу ошибок	Контрольный перечень отчета о состоянии	План управления проектом
Инструкция по измерениям и анализу данных	Контрольный перечень экспертизы требований	План управления конфигурацией
Инструкция по управлению рисками	Контрольный перечень экспертизы требований	Отчет об анализе показателей
Инструкции по трассировке требований	Контрольный перечень экспертизы плана проекта	Отчет о состоянии этапа
Инструкция по предупреждению возникновения ошибок	Контрольный перечень экспертизы кода на C++	Отчет по анализу предупреждения ошибок

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

• План управления проектом
• План управления конфигурацией
• График работ
• Стандарты, контрольные перечни, инструкции, шаблоны и другие пособия
• Разработанные инструменты и замечания по ним
• Обучающие материалы
• Другие документы

Дополнительно к артифактам для регистрации коллективного опыта и знания используется система совокупности знаний (body of knowledge, BOK). BoK базируется в интернете и имеет собственное средство поиска по ключевому слову или по фамилии автора. Данные представлены главным образом в форме статей, организованных по темам:

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

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

• База данных процессов содержит данные по производительности завершенных проектов:
  • Данные по рискам,
  • Трудоемкости и ее распределение
  • Ошибки и их распределение
  • Размер ПО
  • Другие характеристики проекта
• Базовая линия устойчивости процесса суммирует производительность процесса в проектах, определяя тем самым диапазон результатов, которые можно ожидать при соблюдении процесса. Содержи показатели:
  • Качество
  • Продуктивность
  • Эффективность устранения ошибок
  • Распределение трудоемкости
  • Распределение ошибок
• Активы процесса - это документы:
  • Контрольные перечни
  • Шаблоны
  • Методология
  • Инструкции

Можно создать усеченные варианты структуры. Ключевым моментом является выполнение анализа при закрытии проекта. Эти элементы инфраструктуры не соответствуют собственно требованиям KPA CMM в отношении управления проектами. Однако они необходимы для того, чтобы удовлетворять требованиям многих KPA уровней 3 и 4. Существование базы данных процесса, как и управление активами процесса, явно требуется на уровне 3. Базовая линия устойчивости процесса необходима для обоих KPA на уровне 4.

Глава 1. Управление программными проектами

Конспект Pankaj Jalote "Управление программным продуктом на практике"

Каждый год выполняется примерно 1 000 000 проектов, на общую сумму $600 000 000 000. Приблизительно 33% превышают стоимость и отстают по срокам более, чем на 125%. Наиболее важными причинами провала является неправильное управление проектом.

1. маловразумительные цели,
2. плохое планирование,
3. необходимость использования новых технологий,
4. отсутствие методологии управления проектом и
5. недостаточная численность персонала.

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

1. Оценивание трудоемкости
2. Управление рисками
3. Мониторинг проекта
4. Управление конфигурацией и т.д.

Но неясно, как объединить их в один реально выполнимый процесс. Требуется сбалансированный процесс, охватывающий управление всем проектом от начала до конца. 1.1. Процессы и управление проектом 
Деятельность в программном проекте ведется в основном в двух измерениях: в области инженерии и в области управления проектом. Измерение инженерии имеет дело с проектированием, программированием, тестированием и т.п. Измерение управления проектом связано с надлежащим планированием и контролем действий инженерии, которые позволяют достичь целей проекта по стоимости, срокам и качеству. Для простых проектов не требуется высокий уровень формализма при их выполнении. Для более сложных проектов необходим определенный уровень формализма при выполнении проекта, а также строгость планирования и отслеживания запланированных задач. Формализм требует применять четко определенные процессы, поэтому результаты зависят от устойчивости этих процессов. Формализм еще более усиливается, если в процессах используются количественные подходы. Технически процесс для задачи включает последовательность шагов, которой нужно придерживаться при выполнении данной задачи. Однако для любой организации процессы, которые она рекомендует использовать своим инженерам и менеджерам проектов,— не просто последовательности шагов: они заключают в себе то, что инженеры и менеджеры проектов узнали об успешно выполненных проектах. Через процессы преимущества накопленного опыта передаются всем сотрудникам организации, в том числе новичкам. Такие процессы помогают менеджерам и инженерам подражать прошлым успехам и избегать просчетов, ведущих к провалам. Процессы инженерии определяют как выполнить работу. Процессы управления проектом определяют, как

• Установить контрольные точки
• Организовать персонал
• Управлять рисками
• Отслеживать продвижение вперед и т.д.

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

1. Процессы представляют коллективное знание. Их использование повышает шансы на успех
2. Процесс может включать несколько дополнительных шагов, но никогда нельзя знать заранее, каким путем будет развиваться ситуация, поэтому использование коротких путей повышает риски выполнения проекта.
3. Не пользуясь процессами, нельзя предсказать результаты проекта.
4. Вы и ваша организация не сможете обучаться, если не будете пользоваться предопределенными процессами.
5. Процессы снижают уровень опасений. Контрольные перечни неизбежно охватывают 80% того, что необходимо сделать. Вам остается проработать только 20%.

1.2. Управление проектами и CMM 
CMM - the Capability Maturity Model. CMM для ПО является системой понятий, которые пытаются ответить на вопрос, какие должны быть характеристики эффективных процессов, не предписывая никаких конкретных процессов. CMM может использоваться для оценки процесса разработки ПО в организации и для определения его недостатков. Другой стандарт - ISO 9001.

  1.2.1. Обзор CMM 
Незрелость процессов разработки ПО означает, что проекты выполняются без многих необходимых правил, а результаты проекта зависят в значительной степени от руководителя проектом и команды. При использовании зрелых процессов проект выполняется в соответствии с определенными процессами. В этом случае результат меньше зависит от людей и больше от процесса. Чем более зрелые процессы используются, тем более предсказуемы результаты, тем лучше контролируется проект. Устойчивость процесса проекта (process capability) - диапазон результатов проекта, которые получаются как следствие исполнения проекта согласно этого процесса. Производительность процесса (process performance) - фактический результат процесса, полученный в результате использования этого процесса. Таким образом производительность (эффективность) процесса зависит от его устойчивости. Уровень зрелости процессов - определенная стадия, на которой находятся процессы организации, которой соответствуют определенные характеристики. Ключевая область процесса (key process area, KPA) - характеристика каждого уровня зрелости, это те области, на которые организация должна обращать внимание, чтобы поднять свои процессы до данного уровня зрелости (отображены на диаграмме). Чтобы организация достигла уровня определенного уровня зрелости, она должна соответствовать всем KPA это уровня и всем KPA нижних уровней.

  1.2.2. Ключевые области процесса (KPA) для управления проектами 
Каждая KPA задает цели, которым процессы организации должны соответствовать. Также задается Ключевые практики (key practices) - группа действий, которые вместе соответствуют целям KPA.

  Уровень 2 
В таблице перечислены все цели для KPA уровня 2. Почти все внимание отдается управлению проектом.

KPA	Цели
Управление требованиями (управленческая область)	Требования к ПО контролируются для определения базовой линии разработки ПО и управления разработкой В соответствии с требованиями поддерживаются планы разработки ПО, продукты и действия
Планирование программного проекта (управленческая область)	Оценки документируются для использования в процессах планирования и отслеживания проекта Планируются и документируются действия и обязательства по проекту Участвующие группы и отдельные лица принимают на себя обязательства, связанные с проектом.
Отслеживание и надзор за проектом (управленческая область)	Фактические результаты и характеристики сравниваются с планами разработки ПО Если фактические результаты существенно отклоняются от планов, то вносятся поправки, и управление этим процессом не заканчивается до его закрытия Изменения в обязательствах согласовываются с заинтересованными группами и отдельными лицами
Управление субподрядами на разработку ПО (управленческая область)	Главный подрядчик и субподрядчик договариваются о взаимных обязательствах Главный подрядчик отслеживает фактические показатели выполнения обязательств в соответствии с договоренностями Главный подрядчик и субподрядчики поддерживают постоянное взаимодействие Главный подрядчик отслеживает фактическую производительность субподрядчика в соответствии с обязательствами
Обеспечение качества ПО (техническая область)	Планируются действия, обеспечивающие качество ПО Проверяется строгое соответствие программных продуктов и действий применяемым стандартам, процедурам и требованиям Заинтересованные группы и отдельные лица информируются о действиях и результатах, обеспечивающих качество ПО Вопросы несоответствия, которые не могут решиться внутри проекта, направляются высшему менеджменту
Управление конфигурацией ПО (техническая область)	Планируется деятельность по управлению конфигурацией ПО Определяются, контролируются и делаются доступными избранные программные рабочие продукты Контролируются изменения в определенных программных рабочих продуктах Заинтересованные лица информируются о содержании и состоянии базовой линии проекта

Исходя из этих целей:

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

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

KPA	Цели
Интегральное управление разработкой ПО	Определенный для проекта процесс разработки ПО является специализированной версией стандартного процесса разработки ПО в организации Проект планируется и исполняется в соответствии с определенным для него процессом разработки ПО
Межгрупповая организация	Требования заказчика согласовывается всеми заинтересованными сторонами Все стороны согласовывают взаимные обязательства Стороны определяют, отслеживают и разрешают межгрупповые вопросы
Экспертизы специалистов	Планируется проведение экспертиз Определяются и устраняются ошибки в программных рабочих продуктах

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

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

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

  1.3. Управление проектами в компании InfoSys 
1.3.2. Поддержка проектов со стороны SEPG 
SEPG - software engineering process group. Отвечает за координацию всей деятельности, связанную с процессами, в том числе за определение, совершенствование, размещение процессов. Также управляет всей информацией, связанной с использованием процессов и базовой линией устойчивости процесса. Также формирует независимый канал для мониторинга выполнения проекта и отправки отчетов менеджменту по вопросам процесса и качества. Также занимается внедрением процессов в обычную практику. Выделяется сотрудник, который является членом команды проекта и отвечает за качество продукта. Также предоставляет помощь при планировании, обучении. Также проводит экспертизу плана управления проектом.

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

  1.3.4. Обучение менеджеров проектов 
Все новые сотрудники проходят 3-4 месячную ознакомительную обучающую программу:

1. Курсы по инженерии и технологиям
2. Профессиональная этика бизнеса,
3. Правила ведения переписки
4. Публичные выступления
5. Жестикуляция, мимика, …

  Для кандидатов в лидеры модулей ПО/менеджеров проектов:

1. Техническая программа
   1. 5-ти дневная программа по планированию, мониторингу, … проектов.
   2. 2-х недельные курсы по определению требований, документированию, проверке, …
   3. 5-ти дневная программа по оцениванию, управлению командой, общению с заказчиками, лидерству, социальной и деловой этике разных стран, и т.д.
2. Обучающая программы
   1. Разнообразные аспекты управление. PM обучаются, когда позволяет их календарный план.
   2. Рабочие семинары по созданию команды.

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

1. Планирование проекта
2. Выполнение проекта
3. Закрытие проекта

  Планирование проекта
Руководитель проекта изучает контрактные обязательства и разрабатывает план по их выполнению. План проекта:

• Определение процесса жизненного цикла
• Оценивание трудоемкости и сроков работ
• Подготовка детального графика задач
• Управление качеством
• Управление конфигурацией
• Управление рисками

Менеджер проекта:

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

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

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

Менеджер проекта:

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

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

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


1.5. Итоги

• Процессы для различных аспектов управления проектом не следует рассматривать изолированно. В сбалансированном процессе практики интегрируются без помех.
• Процессы организации должны включать ее лучшие практики, чтобы помочь новым проектам воспроизвести достигнутые в прошлом успехи и избежать неудач.
• На верхнем уровне процесс управления проектом включает три стадии:
  • Планирование
  • Исполнение
  • Закрытие
• Для эффективного выполнения проектов менеджеры проектов должны получить поддержку и помощь от SEPG в выполнении процессов, в от вышестоящего руководства - в мониторинге и разрешении проблем. Менеджеры проектов должны пройти качественное обучение.
• Многие ключевые области процесса на всех уровнях зрелости CMM для разработки ПО непосредственно ориентированы на управление проектом.