Цели и Задачи
Формирование концепции решения начинается с выяснения у заинтересованных сторон, описания и фиксации проектной группой целей проекта. Далее каждая цель разбивается на измеримые компоненты - задачи.
В нашем случае цели системы:
работать с аэропортами и рейсами;подобрать клиенту оптимальный маршрут.
Задачи системы:
решать однокритериальную задачу поиска кратчайших путей на графах (критерий - цена); работать с базой данных аэропорта; бронировать билеты; …
Функциональность решения
Хранилище находится в оперативной памятиДобавление аэропортов по нажатию кнопки Проверка корректности введены данных Проверка существования аэропорта с введенным номеромСоздание визуальной формы для отображения аэропортаДобавление рейсов Проверка корректности введены данных
Проверка существования рейса с введенным номеромПроверка на существование аэропортов рейсаДобавление в визуальные формы аэропортов информации о добавленных рейсахУдаление аэропортовУдаление всех сопутствующих рейсовУдаление рейсовПоиск минимального по стоимости маршрутаЗаказ билетов на найденные маршруты
Концепция решения
Концепция решения (solution concept) предоставляет общее описание подходов, которые проектная группа предполагает использовать для разрешения проблем и/или удовлетворения потребностей заинтересованных сторон.
Основные задачи фазы
Основными задачами фазы выработки концепции являются создание ядра проектной группы и подготовка документа общего описания и рамок проекта (vision/scope document). Формирование видения проекта и определение его рамок - не одно и тоже, хотя для успеха проекта необходимо и то, и другое. Видение (vision) - это ничем не ограничиваемое представление о том, каким должно быть решение. Рамки (scope) же дают четкие границы того, что из предложенного этим видением будет реализовано в условиях существующих проектных ограничений.
Также во время фазы выработки концепции производится выявление и анализ бизнес-требований. Более детально эти требования рассматриваются во время фазы планирования.
Наконец, во время данной фазы проектная группа готовит документ оценки рисков и представляет главные риски проекта вместе с общим описанием и рамками проекта.
Ведущим ролевым кластером на фазе выработки концепции является "Управление продуктом".
В начале фазы планирования проектная группа анализирует и документирует проектные требования. Они разделяются на четыре общих категории:
бизнес-требования (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).
Планирование проекта Фаза планирования
На фазе планирования2) (planning) производится основная работа по составлению планов проекта. Она включает в себя подготовку проектной группой функциональной спецификации, разработку дизайнов, подготовку рабочих планов, оценку проектных затрат и сроков разработки различных составляющих проекта.
Пользователи
Основой формулировки требований является анализ использования, включающий определение пользователей (users) и описание того, как пользователи будут взаимодействовать с решением.
В системе будет две группы пользователей:
Менеджеры аэропортаПокупатели билетов
Предположения и Ограничения
В процессе формирования концепции решения проектная группа постоянно взаимодействует с заинтересованными сторонами, собирая необходимую информацию о требованиях к функциональности будущего решения. Тем не менее, неизбежная неполнота информации приводит к тому, что относительно некоторых функциональных возможностей решения могут потребоваться предположения (assumptions). Помимо функциональных требований заинтересованные стороны могут выдвигать качественные требования, задающие ограничения на создаваемое решение. Также ограничения могут порождаться средой, в которой должно будет функционировать решение после внедрения.
В нашем случае на первую вариант системы накладываются следующие ограничения:
система не является распределенной;нет разграничения прав между менеджерами и пользователями; интерфейс системы представлен в одном окне; система должна наглядно демонстрировать формы и способы хранения и взаимодействия данных.
Рамки
Рамки (scope) определяют пространство параметров, в котором будет создаваться решение, детализируя функциональность, определяя, что останется за рамками решения и указывая критерии, по которым заинтересованные лица будут судить о готовности решения. Рамки создаются на основе единого видения, являются результатом компромисса между сформулированными целями и условиями реальности и отражают приоритезацию заказчиком имеющихся требований к создаваемому решению. Частью процесса определения рамок проекта является вынесение менее важной функциональности из текущего проекта в планы на будущее.
Рамки решения (solution scope) определяют функциональность решения и его возможности (включая те, что не относятся к программному обеспечению). Возможность (функциональность, составляющая, feature) - это требуемый или желаемый аспект программного или аппаратного обеспечения. Например, предварительный просмотр перед печатью может быть возможностью текстового процессора; шифрование почтовых сообщений - возможностью почтовой программы. Сопроводительные руководства пользователей, интерактивные файлы помощи, операционные руководства и обучение также могут быть составляющими решения.
Рамки проекта (project scope) определяют объем работ, который должен быть выполнен проектной группой для поставки заказчику каждого из элементов, определенного рамками решения.
Результаты фазы планирования
Результатами фазы планирования являются:
Функциональная спецификация.План управления рисками.Сводный план и сводный календарный график проекта.
Результаты фазы выработки концепции
Результатами фазы выработки концепции являются:
Общее описание и рамки проекта (vision/scope document).Документ оценки рисков (risk assessment document).Описание структуры проекта (project structure document).
Сценарии использования
Сценарии использования (usage scenarios) определяют последовательности действий, которые пользователи выполняют при взаимодействии с решением. MSF не специфицирует явным образом способы описания сценариев использования. Один из возможных (и достаточно распространенных) вариантов - язык UML.
Начнем с диаграммы использования.
Рис. 6.1a.
Затем расшифруем отдельные сценарии.
Рис. 6.1b.
увеличить изображение
Рис. 6.1c.
увеличить изображение
Рис. 6.1d.
Старт проекта Фаза выработки концепции
Внимание! Презентации семинаров и шаблоны к ним находятся
Фаза выработки концепции1) (envisioning phase) - первая фаза жизненного цикла проекта. MSF считает, что одним из фундаментальных факторов успеха проекта является создание и сплочение проектной группы на основе выработки единого видения (shared vision). Проектная группа должна совершенно четко представлять, что она хочет сделать для заказчика, а формулировка цели проекта должна максимально мотивировать как заказчика, так и саму проектную команду. Выработка высокоуровневого взгляда на цели и условия проекта может рассматриваться как ранняя форма планирования; она подготавливает почву для создания детальных планов, которые будут осуществлены непосредственно во время фазы планирования.
Учебный пример Выработка концепции
Рассмотрим учебный пример "Система бронирования билетов для авиакомпании".
Вехи фазы планирования
Кульминацией фазы планирования является веха "Планы проекта утверждены" (project plans approved). Она знаменует собой достижение детального соглашения между проектной группой и ключевыми заинтересованными сторонами о составе поставляемого решения и сроках поставок. Также на этой вехе проектная группа уточняет оценки рисков, корректирует (при необходимости) приоритеты и окончательно оценивает требуемые ресурсы.
Утвержденные спецификации, планы и календарные графики образуют базовую версию проекта (project baseline). Она включает все соглашения, принятые на основе консенсуса с учетом трех плановых параметров проекта: ресурсов, времени и функциональности решения. После того, как базовая версия проекта создана и утверждена, проектная группа приступает к фазе разработки.
Изменения в созданной базовой версии проекта подвергаются строгому контролю. Это не означает, что все принятые во время фазы планирования решения окончательны - в ходе последующей фазы разработки проектная группа должна анализировать и формально утверждать (либо отвергать) все предлагаемые изменения базовой версии.
В течение фазы MSF рекомендует выделить промежуточные вехи:
Верификация технологий (technology validation)
Верификация это проверка соответствия продуктов и технологий, которые предполагается использовать, спецификациям их поставщиков. Это начальный шаг того процесса, который в последствии должен подтвердить выбранную концепцию и, в конце концов, трансформироваться непосредственно в разработку решения.
Зачастую верификация технологий включает в себя отбор наиболее подходящих из конкурирующих технологий.
Базовая версия функциональной спецификации создана
К моменту достижения этой вехи функциональная спецификация готова для распространения среди заинтересованных сторон с целью получения их отзывов. Также начинается контроль изменений, вносимых в подготовленную проектной группой базовую версию спецификации.
Функциональная спецификация является основой создания сводного плана и сводного календарного графика проекта.
Она содержит детальное описание вида и поведения каждой составляющей решения с точки зрения пользователя. Изменения в функциональной спецификации допустимы лишь с одобрения заказчика.
Базовая версия сводного плана проекта создана
В MSF сводный план проекта - это не отдельный самостоятельный план, а совокупность планов работы различных ролевых кластеров. В зависимости от проекта в нем могут быть собраны планы различных типов.
Рис. 6.2. Сводный план проекта (возможный состав). Источник: белая книга
Компоновка различных проектных планов в один сводный документ [6.1] облегчает совместное планирование работы различных ролевых кластеров и составление единого календарного графика проекта, способствует организации отчетности ролевых кластеров, а также помогает выявить имеющиеся в планах изъяны и несоответствия.
Базовая версия сводного календарного графика проекта создана
Сводный календарный график проекта включает в себя все детализированные календарные графики вплоть до даты выпуска решения. Сводный календарный график интегрирует в себе календарное планирование деятельности каждого ролевого кластера. Дата выпуска определяется после обсуждения со всеми заинтересованными сторонами базовой версии функциональной спецификации и анализа сводного плана проекта. Зачастую, с целью обеспечения выпуска решения в намеченный срок, проектная группа вносит коррективы в функциональную спецификацию и/или сводный план проекта. Хотя принимаемая функциональность решения, доступные ресурсы и отведенное для проекта время могут варьироваться, всеобщий настрой на фиксированную дату выпуска решения мобилизует проектную группу, что помогает адекватно оценивать риски, расставлять приоритеты в работе и планировать.
Среды разработки и тестирования развернуты
Во избежание излишних задержек, среды разработки и тестирования должны развертываться немедленно по окончании составления проектных планов. Развертывание включает в себя установку рабочих станций, серверов и необходимого программного обеспечения.Если к данному моменту еще не готовы системы резервного копирования, они также должны быть развернуты. Помимо этого зачастую создаются образы стандартных серверных конфигураций для быстрого восстановления после переформатирования жестких дисков.
Среда тестирования должна быть максимально приближена к производственной. Этого важно достичь даже тогда, когда подготовка такой среды требует больших затрат. В противном случае некоторые специфические ошибки могут остаться не выявленными до момента внедрения решения в производственную среду.
Вехи фазы выработки концепции
Главной вехой фазы выработки концепции является веха "Концепция утверждена".
К этому моменту проектная группа и заказчик должны прийти к соглашению об общих задачах проекта, включаемой и не включаемой в решение функциональности и временных рамках.
В течение фазы MSF рекомендует выделить промежуточные вехи:
Ядро проектной группы сформировано
К этому моменту назначены ключевые члены проектной группы, но, как правило, команда еще не сформирована полностью. До того, как формирование проектной группы завершено, уже приступившие к работе сотрудники могут брать на себя роли отсутствующих членов команды.
Документ описания структуры проекта включает в себя информацию об организации проектной группы, персонификации ролей и ответственности. Также документ описания структуры проекта разъясняет схемы взаимодействия проектной группы с заказчиком и заказчика - с проектной группой.
Черновой вариант концепции проекта составлен
К моменту этой промежуточной вехи появляется черновой вариант документа общего описания и рамок проекта, который с целью получения отзывов распространяется среди членов проектной группы, представителей заказчика и других заинтересованных сторон. Затем происходит итеративная доработка документа, включающая в себя рассмотрение полученных отзывов, их обсуждение и внесение изменений.
Видение проекта
Формулировка видения (vision statement) должна быть достаточно краткой для запоминания, достаточно ясной для понимания и достаточно сильной для мотивирования.
Представим возможный вариант.
Разработанная система бронирования билетов позволит авиакомпании "GlobalAvia" повысить эффективность управления рейсами и даст возможность клиентам компании самостоятельно подбирать маршруты (в том числе с пересадками) с оптимальной стоимостью. Через год разработанное решение позволит авиакомпании увеличить число своих клиентов не менее чем в 1.5 раза.
Вспоминая предыдущую лекцию
Наша предыдущая лекция была посвящена управлению рисками и модели процессов в MSF.
Мы обсудили, что такое риски в понимании MSF, зачем необходимо планирование управления рисками. Поговорили о том, из каких стадий состоит процесс управления рисками в MSF. Рассмотрели место управления рисками в жизненном цикле программного продукта.
Далее были подробно описаны принципы модели процессов MSF и составляющие схемы процесса разработки.
За рамками решения
Распределенное хранилище не будет реализовано в первой версииРаздельное приложение для менеджеров и клиентов не будет реализовано в первой версииПоиск всех имеющихся маршрутов не будет реализован в первой версии
Задачи ролевых групп на фазе планирования
Основные задачи и сферы ответственности каждого из ролевых кластеров проектной группы во время фазы планирования рассмотрим в виде таблицы.
| Управление продуктом | Концептуальный дизайн; анализ бизнес-требований; коммуникационный план |
| Управление программой | Концептуальный и логический дизайн; функциональная спецификация; сводный план и сводный календарный график проекта; бюджет |
| Разработка | Оценка технологий; логический и физический дизайн; план и календарный график разработки; смета разработки (development estimates) |
| Удовлетворение потребителя | Сценарии/примеры использования, пользовательские требования, требования локализации и общедоступности (accessibility); пользовательская документация/план обучения/график тестирования удобства эксплуатации; обучение |
| Тестирование | Оценка дизайна; требования тестирования; план и календарный график тестирования |
| Управление выпуском | Оценка дизайна; эксплуатационные требования; план и календарный график пилотного и окончательного внедрения |
Задачи ролевых групп на фазе выработки концепции
Основные задачи и сферы ответственности каждого из ролевых кластеров проектной группы во время фазы выработки концепции рассмотрим в виде таблицы.
| Управление продуктом | Общие цели проекта; выявление нужд и требований заказчика; документ общего описания и рамок проекта. |
| Управление программой | Цели дизайна; концепция решения; структура проекта |
| Разработка | Прототипирование; анализ технологических возможностей; анализ осуществимости |
| Удовлетворение потребителя | Необходимые эксплуатационные характеристики решения и их влияние на его разработку |
| Тестирование | Стратегии тестирования; критерии приемлемости, их влияние на разработку решения |
| Управление выпуском | Требования внедрения и их влияние на разработку решения; требования сопровождения |
Основные задачи фазы
Во время фазы стабилизации2) производится тестирование разработанного решения. При этом внимание фокусируется на его эксплуатации в реалистичной модели производственной среды. Проектная группа занимается приоритезацией и устранением ошибок, а также подготовкой решения к выпуску.
Обычно в начале фазы стабилизации скорость выявления ошибок командой тестирования превосходит скорость, с которой эти ошибки могут устраняться командой разработчиков. Невозможно предсказать, сколько ошибок будет найдено и как много времени понадобится на их устранение. Однако существует два статистических признака, помогающих проектной группе оценить уровень стабилизации решения. Это точка конвергенции (bug convergence) и точка достижения нуля ошибок (zero bug bounce). Они описываются ниже.
MSF не использует для описания состояния проекта термины "альфа" и "бета". Хотя эти понятия применяются довольно часто, их интерпретация далеко не однозначна. При желании проектная группа может их использовать, но при этом они должны быть четко определены и понятны как членам проектной группы, так и заказчику и другим заинтересованным сторонам.
Как только создана версия, достаточно стабильная для того, чтобы считаться кандидатом для выпуска, производится пилотное внедрение решения.
Основные задачи фазы
Во время этой фазы проектная группа внедряет3) технологии и компоненты решения, стабилизирует внедренное решение, передает работу персоналу поддержки и сопровождения и получает со стороны заказчика окончательное одобрение результатов проекта. По завершению внедрения проектная группа производит анализ выполненной работы и удовлетворенности заказчика.
Во время этой фазы по ходу переноса компонент решения из среды тестирования в производственную среду могут продолжаться меры по стабилизации решения.
Разработка решения Фаза разработки
Внимание! Презентации семинаров и шаблоны к ним находятся
Результаты фазы разработки
Результатами фазы разработки являются:
Исходный и исполнимый код приложений.Скрипты установки и конфигурирования.Окончательная функциональная спецификация.Материалы поддержки решения.Спецификации и сценарии тестов.
Результаты фазы стабилизации
Результатами фазы стабилизации являются:
Окончательный продукт (golden release).Документация выпуска (release notes).Материалы поддержки решения.Результаты и инструментарий тестирования.Исходный и исполнимый код приложений.Проектная документация.Анализ пройденной фазы (milestone review).
Результаты фазы внедрения
Результаты фазы внедрения включают в себя:
Информационные системы эксплуатации и поддержки.Процедуры и процессы.Базы знаний, отчеты, журналы протоколов.Версии проектных документов, массивы данных и программный код, разработанные во время проекта.Отчет о завершении проекта (project close-out report).Окончательные версии всех проектных документов.Показатели удовлетворенности заказчика и потребителей.Описание последующих шагов.
 |
|
|
1)
Раздел подготовлен на основе материалов белой книги [7.1]
2)
Раздел подготовлен на основе материалов белой книги [7.1]
3)
Раздел подготовлен на основе материалов белой книги [7.1]
Вехи фазы разработки
Веха "Разработка завершена" является кульминацией фазы разработки. К моменту ее наступления создание всех составляющих завершено, и решение готово к тестированию и стабилизации. Заказчики, потребители, персонал сопровождения и другие заинтересованные стороны получают возможность оценить решение и выявить все оставшиеся проблемы и неурегулированные вопросы, которые должны быть улажены до выпуска решения.
В течение фазы MSF рекомендует выделить промежуточные вехи:
Концепция подтверждена
Подтверждение концепции (proof of concept) включает в себя проверку ключевых элементов решения в непроизводственной копии существующей среды. Проектная группа демонстрирует группе сопровождения и потребителям все аспекты решения с целью верификации сформулированных требований.
Билд n завершен, билд n+1 завершен...
Поскольку центром внимания фазы разработки является создание решения, проектной группе необходимо установить промежуточные вехи, помогающие определить прогресс в этой работе.
Разработка ведется параллельно и сегментировано, поэтому возникает потребность в единой мере общего прогресса. Промежуточные билды предоставляют такую меру, заставляя команду разработчиков синхронизировать различные составляющие на уровне решения в целом.
В зависимости от проекта, количество промежуточных билдов и частота их создания может меняться.
Зачастую имеет смысл устанавливать вехи завершения (фиксации) графического дизайна и разработки базы данных, так как от этих составляющих зависит очень многое.
Вехи фазы стабилизации
Фаза стабилизации завершается вехой "Готовность решения утверждена" (release readiness approved). В состоянии, достигнутом к этому моменту, решение уже готово к полному внедрению в производственную среду.
К моменту наступления этой вехи проектная группа завершает разрешение всех существенных проблем и происходит выпуск или внедрение решения. Ответственность за непрерывное управление и поддержку решения формально переходит от проектной группы к командам сопровождения.
В течение фазы MSF рекомендует выделить промежуточные вехи:
Точка конвергенции
В точке конвергенции (bug convergence)[7.1] становится заметен существенный прогресс в устранении ошибок, то есть скорость устранения ошибок начинает превосходить скорость их обнаружения.
Рис. 7.1. Точка конвергенции. Источник: белая книга
Поскольку количество найденных, но не устраненных ошибок может колебаться даже после того, как оно начало убывать, конвергенция может рассматриваться скорее как тенденция, нежели как фиксированный момент во времени. Вслед за этой вехой количество активных ошибок должно продолжать убывать, вплоть до точки достижения нуля. Точка конвергенции дает проектной группе возможность понять, что процесс тестирования близится к концу.
Точка достижения нуля (zero-bug bounce) [7.1]
Это момент, когда впервые все выявленные ошибки оказываются устраненными. Вслед за ней пики количества активных ошибок должны становиться все меньше, вплоть до полного угасания в момент, когда решение уже достаточно стабильно для выпуска первой версии кандидата.
Рис. 7.2. Точка достижения нуля . Источник: белая книга
Существенную роль играет тщательная приоритезация ошибок, поскольку устранение всякой из них содержит риск внесения новых ошибок. Точка достижения нуля ясно показывает, что проектная группа приближается к созданию стабильной версии кандидата (release candidate).
Заметим, что новые ошибки после достижения этой вехи наверняка будут найдены. Однако точка достижения нуля - это первый момент в работе над проектом, когда команда может честно отчитаться об отсутствии активных ошибок и сфокусироваться на сохранении этого состояния.
Версии-кандидаты
Для пилотной группы подготавливается и выпускается серия версий-кандидатов. Выпуск каждой из них является промежуточной вехой. Эти версии имеют следующие особенности:
Каждая версия-кандидат имеет полный набор составляющих, необходимых для внедрения решения в производство.Создание версии-кандидата служит тестом готовности решения к выпуску, то есть проверяет готовность всех его составляющих.Период тестирования, следующий за созданием каждой версии-кандидата, определяет, пригодна ли созданная версия к внедрению, или же проектная группа должна подготовить новую версию-кандидат, исправляющую недостатки предыдущей.Тестирование версий-кандидатов, проходящее внутри проектной группы, требует высокой степени концентрации и интенсивности работы.Маловероятно, что первая версия-кандидат окажется заключительной.Контрольное тестирование завершено (pre-production test complete)
Суть этой промежуточной вехи заключается в подготовке к пилотному выпуску решения. Данная веха очень важна, поскольку наступает момент, когда решение "столкнется" с производственной средой, и проектная группа должна как можно тщательнее оттестировать решение до этого момента, - до начала испытания пилотного выпуска.
К данной вехе проектная группа должна:
Оценить результаты тестирования в соответствии с имеющимися критериями успешности.Подготовить среду внедрения.Создать необходимые для внедрения процедуры, скрипты, массивы данных.Иметь готовые учебные материалы.Обеспечить условия для сопровождения решения.Создать и протестировать план "отката" (rollback plan).
Данная веха может считаться пройденной лишь после обретения проектной группой полной уверенности в готовности всего, что необходимо для внедрения решения.
Тестирование приемлемости для потребителей завершено
Тестирование приемлемости для потребителей (user acceptance testing) и исследование эргономичности (usability studies) выполняются начиная с фазы разработки и продолжаются на протяжении фазы стабилизации.
Их цель - убедиться в том, что новая система отвечает требованиям потребителей и бизнеса.
По достижению данной вехи пользователи осуществляют тестирование и одобряют работу решения в непроизводственной среде (non-production environment). Это включает в себя проверку интеграции системы с работающими в производственной среде бизнес приложениями. Также должны быть проверены разработанные процедуры "отката" и восстановления после сбоев (rollout and backout procedures).
После одобрения менеджерами выпуска, разработанное программное обеспечение и все докупленные к нему компоненты переносятся из архива группы разработки в архив группы сопровождения.
Пилотное внедрение завершено
Во время этой промежуточной вехи проектная группа тестирует решение целиком в среде, максимально приближенной к производственным условиям. В MSF пилотный релиз (pilot release) - это внедрение решения в часть производственной среды или для части пользователей. В зависимости от проекта, пилотный релиз может принимать различные формы.
На предприятии это может быть релиз для группы пользователей или подмножества серверов данных.Для веб-разработки это может быть хостинг на тестовых серверах или в подкаталогах, которые доступны в Internet только через тестовый веб-адрес.Производители коммерческого программного обеспечения, такие как Microsoft, часто выпускают новый программный продукт для специальной группы "первоиспытателей" до того, как будет создана окончательная его версия.
Общим для всех этих форм предварительно выпуска является максимальное приближение тестирования к реальным условиям.
Веха "Пилотное внедрение завершено" не может считаться пройденной, пока проектная группа не удостоверилась окончательно, что созданное решение жизнеспособно в производственной среде, и каждая его компонента готова к внедрению.
Как только в результате пилотного внедрения накоплено и проанализировано достаточное количество данных, проектной группе необходимо принять решение о дальнейших действиях.Возможны следующие варианты:
Шаг вперед: пилотное внедрение нового релиза.Откат назад: выполняется план отката, и пилотная группа возвращается к конфигурациям, существовавшим до пилотного внедрения. Позднее попытка пилотного внедрения будет повторена вновь с более стабильной версией решения.Приостановка: пилотная версия "замораживается".Исправление и продолжение: пилотная группа получает "заплатку" (patch) к существующему коду.Переход к фазе внедрения.
Вехи фазы внедрения
Главная веха фазы: "Внедрение завершено". Данная веха - кульминация фазы внедрения. К этому времени решение должно начать давать заказчику ожидаемую бизнес-отдачу, а проектная группа - свернуть свою деятельность.
Прежде чем считать решение запущенным в эксплуатацию и свернуть проект, проектная группа должна получить от заказчика подтверждение того, что его цели достигнуты. Для этого решение должно быть стабильным и четко удовлетворять выработанным критериям успешности. Стабильность решения означает также готовность систем его эксплуатации и сопровождения.
В течение фазы MSF рекомендует выделить промежуточные вехи:
Ключевые компоненты развернуты (core components deployed).
Большинство инфраструктурных решений включают в себя ряд компонент, образующих основу всего решения. С точки зрения отдельных пользователей, сами эти компоненты не имеют самостоятельной ценности. Однако внедрение полного решения зависит от ключевых компонент. Кроме того:
Компоненты могут обеспечивать функционирование ключевых технологий внедряемого решения. Например, это могут быть контроллеры доменов, маршрутизаторы, почтовые серверы, удаленные серверы доступа, серверы баз данных. Внедрение на местах может зависеть от этих технологий. При этом может быть необходимым внедрение ключевых технологий до внедрения всего решения или параллельно с его внедрением на местах.Для предотвращения задержек, ключевые компоненты могут быть рассмотрены и утверждены к внедрению еще до того, как другие части решения стабилизированы. При этом персонал сопровождения должен быть уверен в надежности ключевых компонент.Внедрение на местах завершено (site deployments complete)
К моменту прохождения этой вехи все целевые потребители получают доступ к решению. Лица, ответственные за участки внедрения, подписывают акты о пуске решения в эксплуатацию, хотя определенные проблемы все еще могут возникать.
На этом этапе проектная группа концентрируется на завершении мероприятий по внедрению и на сворачивании проекта.
Многие проекты, в особенности веб-разработки, не подразумевают внедрения на местах, поэтому данная веха к ним не применима.
Внедренное решение стабилизировано
К моменту этой вехи заказчик и проектная группа приходят к соглашению о том, что решение функционирует правильно. Однако нужно понимать, что все еще могут возникать некоторые проблемы на местах. Они должны отслеживаться и разрешаться. Тем не менее, проектной группе важно четко зафиксировать точку завершения внедрения, а не пытаться достичь идеального состояния решения.
Если заказчик ожидает, что члены проектной команды будут участвовать в поддержке и сопровождении решения, после завершения проекта соответствующие сотрудники должны быть переведены на новые роли в структуре сопровождения.
На этой стадии, по всей вероятности, члены проектной группы и внешние заинтересованные лица начнут выходить из проекта.
Частью выхода из проекта является передача функций эксплуатации и сопровождения решения постоянному персоналу. Во многих случаях для этого уже будут нужные ресурсы. В других ситуациях может понадобиться разработка новой системы поддержки. Учитывая объемность такой задачи, разумно рассматривать ее как отдельный проект.
Вспоминая предыдущую лекцию
Наша предыдущая лекция была посвящена фазам выработки концепции и планирования в MSF.
Для каждой фазы мы рассмотрели:
Основные задачи фазыЗадачи ролевых группВехи фазыРезультаты фазы
Также обсудили учебный пример применительно к действиям, которые должны выполняться в течение указанных фаз.
Задачи ролевых групп на фазе разработки
Основные задачи и сферы ответственности каждого из ролевых кластеров проектной группы во время фазы разработки рассмотрим в виде таблицы.
| Управление продуктом | Ожидания заказчика |
| Управление программой | Управление функциональной спецификацией; мониторинг проекта; доработка планов |
| Разработка | Разработка программного кода и инфраструктуры; документирование конфигураций |
| Удовлетворение потребителя | Обучение; доработка плана обучения; тестирование удобства эксплуатации (usability testing); графический дизайн |
| Тестирование | Функциональное тестирование; выявление проблем; тестирование документации; доработка плана тестирования |
| Управление выпуском | Чеклисты развертывания (rollout checklists); доработка планов внедрения (включая пилотное внедрение); чеклисты подготовки к внедрению (site preparation checklists) |
Задачи ролевых групп на фазе стабилизации
Основные задачи и сферы ответственности каждого из ролевых кластеров проектной группы во время фазы стабилизации рассмотрим в виде таблицы.
| Управление продуктом | Исполнение коммуникационного плана; планирование премьеры продукта |
| Управление программой | Мониторинг проекта; приоритезация ошибок |
| Разработка | Устранение ошибок; оптимизация программного кода |
| Удовлетворение потребителя | Доработка эксплуатационных руководств; учебные материалы |
| Тестирование | Тестирование; сообщение об ошибках и их статусе; тестирование конфигурации |
| Управление выпуском | Развертывание и поддержка пилотного внедрения; планирование внедрения; обучение персонала сопровождения |
Задачи ролевых групп на фазе внедрения
Основные задачи и сферы ответственности каждого из ролевых кластеров проектной группы во время фазы внедрения рассмотрим в виде таблицы.
| Управление продуктом | Получение отзывов и оценок заказчика; акт о приеме выполненной работы |
| Управление программой | Сопоставление рамок проекта с поставленным решением; управление стабилизацией |
| Разработка | Разрешение проблем; поддержка эскалации |
| Удовлетворение потребителя | Обучение; управление календарным графиком обучения |
| Тестирование | Тестирование производительности |
| Управление выпуском | Управление внедрением; одобрение изменений |
