Выработка концепции. Планирование

За рамками решения

• Распределенное хранилище не будет реализовано в первой версии
• Раздельное приложение для менеджеров и клиентов не будет реализовано в первой версии
• Поиск всех имеющихся маршрутов не будет реализован в первой версии

3. Планирование проекта. Фаза планирования

На фазе планирования^{2Раздел подготовлен на основе материалов белой книги [6.1]} (planning) производится основная работа по составлению планов проекта. Она включает в себя подготовку проектной группой функциональной спецификации, разработку дизайнов, подготовку рабочих планов, оценку проектных затрат и сроков разработки различных составляющих проекта.

3.1. Основные задачи фазы

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

• бизнес-требования (business requirements);
• потребительские требования (user requirements);
• эксплуатационные требования (operational requirements);
• системные требования, относящиеся к решению в целом (system requirements).

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

Процесс проектирования - это систематический способ продвижения от абстрактных концепций к конкретным техническим деталям. Он начинается с методичного анализа профилей пользователей (user profiles, иногда называемых "персонажами" - "personas"), которые описывают различные типы пользователей и их рабочие функции. Значительная часть этой работы часто проводится во время фазы выработки концепции. Затем формируется набор сценариев использования (usage scenarios), в каждом из которых моделируется выполнение какой-либо операции определенным типом пользователя. В конце концов, каждый сценарий использования разбивается на последовательность специфических действий, называемых вариантами использования (use cases), которые необходимо выполнить пользователю для осуществления операции.

Существует три уровня процесса проектирования:

• концептуальный дизайн (conceptual design);
• логический дизайн (logical design);
• физический дизайн (physical design).

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

Результаты процесса проектирования документируются в функциональной спецификации (functional specification). Функциональная спецификация детально описывает вид и поведение каждой составляющей решения. Также для всех составляющих описывается их архитектура и дизайн.

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

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

Члены проектной группы, представляющие каждый из ролевых кластеров, оценивают необходимое для выполнения запланированных задач время и составляют календарный график сдачи результатов. Затем происходит синхронизация календарных графиков с последующей их интеграцией в сводный календарный график проекта (master project schedule).

3.2. Задачи ролевых групп на фазе планирования

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

3.3. Вехи фазы планирования

Кульминацией фазы планирования является веха "Планы проекта утверждены" (project plans approved). Она знаменует собой достижение детального соглашения между проектной группой и ключевыми заинтересованными сторонами о составе поставляемого решения и сроках поставок. Также на этой вехе проектная группа уточняет оценки рисков, корректирует (при необходимости) приоритеты и окончательно оценивает требуемые ресурсы.

Утвержденные спецификации, планы и календарные графики образуют базовую версию проекта (project baseline). Она включает все соглашения, принятые на основе консенсуса с учетом трех плановых параметров проекта: ресурсов, времени и функциональности решения. После того, как базовая версия проекта создана и утверждена, проектная группа приступает к фазе разработки.

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

В течение фазы MSF рекомендует выделить промежуточные вехи:

• Верификация технологий (technology validation)

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

  Зачастую верификация технологий включает в себя отбор наиболее подходящих из конкурирующих технологий.
• Базовая версия функциональной спецификации создана

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

  Функциональная спецификация является основой создания сводного плана и сводного календарного графика проекта. Она содержит детальное описание вида и поведения каждой составляющей решения с точки зрения пользователя. Изменения в функциональной спецификации допустимы лишь с одобрения заказчика.
• Базовая версия сводного плана проекта создана

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

  

  
  Рис. 6.2. Сводный план проекта (возможный состав). Источник: белая книга

  Компоновка различных проектных планов в один сводный документ [6.1] облегчает совместное планирование работы различных ролевых кластеров и составление единого календарного графика проекта, способствует организации отчетности ролевых кластеров, а также помогает выявить имеющиеся в планах изъяны и несоответствия.
• Базовая версия сводного календарного графика проекта создана

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

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

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

3.4. Результаты фазы планирования

Результатами фазы планирования являются:

• Функциональная спецификация.
• План управления рисками.
• Сводный план и сводный календарный график проекта.

4. Что дальше?

Тема следующей лекции - Фазы "Разработка", "Стабилизация", "Внедрение" в методологии MSF.