Вехи фазы планирования
Кульминацией фазы планирования является веха "Планы проекта утверждены" (project plans approved). Она знаменует собой достижение детального соглашения между проектной группой и ключевыми заинтересованными сторонами о составе поставляемого решения и сроках поставок. Также на этой вехе проектная группа уточняет оценки рисков, корректирует (при необходимости) приоритеты и окончательно оценивает требуемые ресурсы.
Утвержденные спецификации, планы и календарные графики образуют базовую версию проекта (project baseline). Она включает все соглашения, принятые на основе консенсуса с учетом трех плановых параметров проекта: ресурсов, времени и функциональности решения. После того, как базовая версия проекта создана и утверждена, проектная группа приступает к фазе разработки.
Изменения в созданной базовой версии проекта подвергаются строгому контролю. Это не означает, что все принятые во время фазы планирования решения окончательны - в ходе последующей фазы разработки проектная группа должна анализировать и формально утверждать (либо отвергать) все предлагаемые изменения базовой версии.
В течение фазы MSF рекомендует выделить промежуточные вехи:
- Верификация технологий (technology validation)
Верификация это проверка соответствия продуктов и технологий, которые предполагается использовать, спецификациям их поставщиков. Это начальный шаг того процесса, который в последствии должен подтвердить выбранную концепцию и, в конце концов, трансформироваться непосредственно в разработку решения.
Зачастую верификация технологий включает в себя отбор наиболее подходящих из конкурирующих технологий.
- Базовая версия функциональной спецификации создана
К моменту достижения этой вехи функциональная спецификация готова для распространения среди заинтересованных сторон с целью получения их отзывов. Также начинается контроль изменений, вносимых в подготовленную проектной группой базовую версию спецификации.
Функциональная спецификация является основой создания сводного плана и сводного календарного графика проекта.
Она содержит детальное описание вида и поведения каждой составляющей решения с точки зрения пользователя. Изменения в функциональной спецификации допустимы лишь с одобрения заказчика. - Базовая версия сводного плана проекта создана
В MSF сводный план проекта - это не отдельный самостоятельный план, а совокупность планов работы различных ролевых кластеров. В зависимости от проекта в нем могут быть собраны планы различных типов.
Рис. 6.2. Сводный план проекта (возможный состав). Источник: белая книга
Компоновка различных проектных планов в один сводный документ [6.1] облегчает совместное планирование работы различных ролевых кластеров и составление единого календарного графика проекта, способствует организации отчетности ролевых кластеров, а также помогает выявить имеющиеся в планах изъяны и несоответствия. - Базовая версия сводного календарного графика проекта создана
Сводный календарный график проекта включает в себя все детализированные календарные графики вплоть до даты выпуска решения. Сводный календарный график интегрирует в себе календарное планирование деятельности каждого ролевого кластера. Дата выпуска определяется после обсуждения со всеми заинтересованными сторонами базовой версии функциональной спецификации и анализа сводного плана проекта. Зачастую, с целью обеспечения выпуска решения в намеченный срок, проектная группа вносит коррективы в функциональную спецификацию и/или сводный план проекта. Хотя принимаемая функциональность решения, доступные ресурсы и отведенное для проекта время могут варьироваться, всеобщий настрой на фиксированную дату выпуска решения мобилизует проектную группу, что помогает адекватно оценивать риски, расставлять приоритеты в работе и планировать. - Среды разработки и тестирования развернуты
Во избежание излишних задержек, среды разработки и тестирования должны развертываться немедленно по окончании составления проектных планов. Развертывание включает в себя установку рабочих станций, серверов и необходимого программного обеспечения.Если к данному моменту еще не готовы системы резервного копирования, они также должны быть развернуты. Помимо этого зачастую создаются образы стандартных серверных конфигураций для быстрого восстановления после переформатирования жестких дисков.
Среда тестирования должна быть максимально приближена к производственной. Этого важно достичь даже тогда, когда подготовка такой среды требует больших затрат. В противном случае некоторые специфические ошибки могут остаться не выявленными до момента внедрения решения в производственную среду.
