Определение рамок на этапе выработки концепции

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

Во время фазы выработки концепции (envisioning phase) проектная группа формирует общее видение решения. Затем, исходя из этого видения, определяется начальная версия рамок (scope) решения и проекта. Все это представляется в документе “Общее описание и рамки проекта” (vision/scope document) и подлежит одобрению со стороны проектной группы, заказчика и других заинтересованных сторон до того, как работа над проектом продолжена. Во время этой фазы есть лишь общее понимание рамок на уровне описания функциональности.

Рамки решения и рамки проекта

Термин “рамки” может обозначать как рамки решения (solution scope), так и рамки проекта (project scope). Рамки решения – это совокупность его составляющих и функциональности, которая должна быть создана. Рамки проекта – это объем работы, который необходимо выполнить для создания решения.

Для создания рамок решения в MSF служит процесс проектирования[*].

Определение рамок (scope definition)

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

Определяя рамки, проектная группа выявляет типы задач и навыков, необходимых для создания каждой составляющей решения. Данная информация вносится в документ описания иерархической структуры работ (Work breakdown structure - WBS), который подробно рассматривается ниже.

Управление изменениями рамок (scope change control)

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

Полноценное управление рамками включает в себя принятие компромиссных решений. Используемые в MSF треугольник компромиссов (trade-off triangle) и матрица компромиссов (trade-off matrix) облегчают управление изменениями.

Для получения более детальной информации, см. “Белую книгу” модели процессов MSF.

Подготовка планов

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

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

Хотя уточнение планов производится на каждой из фаз, основная деятельность по планированию приходится на фазу планирования (planning phase).

Вот общая последовательность процессов этой фазы:

· Процесс проектирования (design - что создавать?)

· Процесс планирования (planning - как создавать?)

· Разработка календарного графика (scheduling - когда создавать?)

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

Далее в данном разделе обсуждается планирование.

Повторное использование документов

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

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

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

Планы проекта

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

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

План	Ведущий ролевой кластер
Коммуникационный план	Управление продуктом
План разработки	Разработка
План обучения	Удовлетворение потребителя
План мер безопасности	Разработка, Управление выпуском
План тестирования	Тестирование
План финансирования	Управление программой
План внедрения	Управление выпуском
План закупок и материального обеспечения	Управление выпуском, Управление программой
План пилотного внедрения	Управление выпуском