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

Шаблоны фазы внедрения коробочный продукт заказной продукт

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

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

Персонал для осуществления внедрения Требования к персоналу выше, чем во время фазы построения Специалисты по поддержке Специалисты, знающие детали Технические писатели Архитектор

Критерии внедрения Все ли ключевые функции проверяются Руководит ли заказчик приемо- сдаточным тестированием? Достаточно ли хороши материалы для пользователей? Необходимость в учебных материалах? Удовлетворены ли пользователи?

Основные потоки работ притухли

Работа на фазе внедрения Подготовка бета-версии. Установка этой версии на площадке тестирования. Работа с сообщениями бета-тестеров. Адаптация исправленного продукта под условия пользователей. Завершение артефактов проекта. Определение факта окончания проекта

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

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

Серьезные проблемы Некоторые дефекты могут потребовать проведения дополнительной итерации и тестированиея: Архитектор следит, чтобы проблему не решали так, что вся архитектура развалилась. Если деятельность на этой фазе может повлиять на архитектуру, архитектор ее изменяет. Менеджер проекта должен взвесить затраты.

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

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

Контроль прогресса Менеджер проекта сравнивает реальный прогресс в фазе с графиком, усилиями и затратами, запланированными на эту фазу. В конце фазы внедрения (и всего проекта) определяется: выполнила ли команда поставленные перед ней задачи; причины невыполнения.

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

Экспертиза законченного проекта Цель получить сведения, которые помогут лучше организовать дальнейшие проекты. Например: причины выбора используемой архитектуры и отказа от других архитектур. Требуется ли сотрудникам общее обучение? В каких областях необходимо специальное обучение? Следует ли продолжать наставничество? Поможет ли приобретенный опыт в будущих проектах?

Основные результаты Собственно программное обеспечение. Юридическая документация контракты, лицензионные соглашения, отказы от претензий, гарантии. Полный корректный базовый уровень выпуска продукта, включая все модели системы. Полное и исправленное архитектурное описание продукта. Руководства для пользователей, операторов, системных администраторов и учебные материалы. Ссылки на службу поддержки пользователей и web- страницы, на которых можно найти дополнительную информацию, сообщить об ошибках и получить «заплатки» и обновления.