Этап 4: выпуск окончательной версии

Окончательная версия продукта — это версия-кандидат, качество и состав которой устраивают всех участников проекта, в том числе, членов проектной группы и заказчика. Эта версия не требует ни дальнейшей разработки, ни дополнительного тестирования — именно ее «пакуют в коробку». Решение о выпуске окончательной версии никогда не бывает простым. Основная цель — выпуск продукта с заданными характеристиками в установленные сроки, поэтому прежде всего необходимо ответить на вопрос, отвечает ли версия-кандидат требованиям заказчика. Кроме того, надо принять во внимание результаты анализа проблем, результаты тестирования версии-кандидата и возможность ее сопровождения. Как и всякое ответственное решение, решение о придании кандидату статуса окончательной версии сопряжено со многими рисками и должно приниматься коллегиально.

Управление рисками

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

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

Этап «Выпуск продукта» и его результаты

Достижение этапа «Выпуск продукта» — главная задача проектной группы. Он знаменует завершение работы над продуктом и готовность всех его составляющих к развертыванию. Кроме того, на этом этапе происходит перераспределение ответственности за продукт — от группы разработки к группе логистики и сопровождения. С точки зрения проекта этап «Выпуск продукта» свидетельствует об успешной реализации концепции. Не забудьте отпраздновать этот момент — он означает, что цели проекта достигнуты.

По окончании стадии «Стабилизация» проектная группа начинает этап «Выпуск продукта». Его результаты ложатся в основу процесса развертывания продукта и его эксплуатации.

Для достижения этапа «Выпуск продукта» необходимы следующие результаты:

• окончательная версия продукта — исходные тексты и исполняемые модули;

• документация к окончательной версии — описание окончательной версии и последних изменений, не отраженных в документации продукта;

• материалы для сопровождения приложения и поддержки пользователей — окончательная версия учебных и инструктивных материалов;

• результаты тестирования — база данных выявленных проблем необходима как для сопровождения продукта, так и для будущих проектов;

• архивы проекта — вся информация, имеющая отношение к продукту и его разработке, независимо от того, вошла она в окончательный выпуск или нет;

• документация — вся документация проекта, включая ее версии для каждого промежуточного этапа.

Документация к окончательной версии

При выпуске окончательной версии в продукт всегда вносятся изменения, не отраженные в документации продукта. Чтобы «заткнуть эту брешь», создается документ, где вкратце описаны эти вопросы, а также вопросы совместимости и другие проблемы, которые могут возникнуть при развертывании продукта.

Материалы для сопровождения приложения и поддержки пользователей

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

Документация для пользователей

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

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

Обучение пользователей и необходимые для этого материалы

На стадии стабилизации проектной группе следует разработать план обучения пользователей и соответствующую документацию. Формы обучения могут быть самыми разнообразными: самообучение, обучение под руководством инструктора или неформальные беседы «один на один»; конкретный метод определяется масштабом продукта и организации. Независимо от избранной формы, необходимо предусмотреть как первоначальное обучение пользователей на стадии развертывания (первое знакомство), так и дополнительное — после приобретения пользователями некоторого опыта работы с продуктом.

Сопровождающие материалы

Документация приложения может состоять из нескольких частей.

Если в состав приложения входит СУБД и данные, пригодится серверная документация. Часто приходится структурировать документацию, описывая отдельно вопросы установки, конфигурирования и т. д.

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

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

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

Результаты тестирования

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

Архивы проекта

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

Развертывание

Методы развертывания приложений весьма разнообразны. Для распространения программы установки (или всего выпуска) на клиентские рабочие станции можно воспользоваться такими средствами, как Microsoft Systems Management Server (SMS), регистрационные сценарии, рассылка электронной почтой и распространение через Web.

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

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

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

Регистрационные сценарии — самый простой, быстрый и эффективный метод развертывания, однако здесь понадобится участие пользователей (им придется зарегистрироваться для запуска сценария). Кроме того, иногда оказывается, что у пользователей недостаточно полномочий для выполнения установки. При отсутствии жесткого контроля безопасности регистрационные сценарии должны работать успешно.

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

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