Среды разработки и тестирования развернуты

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

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

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

Если в организации отсутствует отвечающая требованиям проекта лаборатория тестирования, её необходимо создать. Среда тестирования должна быть максимально приближена к производственной. Этого важно достичь даже тогда, когда подготовка такой среды требует больших затрат. В противном случае ряд специфических ошибок может остаться невыявленым до момента внедрения решения в производственную среду. Организации, применяющие MOF, могут воспользоваться информацией из базы данных управления конфигурациями (Configuration Management Database - CMDB) для воспроизведения в тестовой среде всех характеристик реальной производственной среды.

Фаза разработки

Введение

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

Следует обратить внимание, что активность проектной команды на этом этапе не ограничивается написанием разработчиками кода – все ролевые кластеры принимают деятельное участие в создании и тестировании решения.

Веха “Разработка завершена”

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

Результаты

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

· Исходный и исполнимый код приложений.

· Скрипты установки и конфигурирования.

· Окончательная функциональная спецификация.

· Материалы поддержки решения.

· Спецификации и сценарии тестов.

Основные задачи проектной группы на фазе разработки

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

Ролевой кластер	Фокус
Управление продуктом	Ожидания заказчика.
Управление программой	Управление функциональной спецификацией; мониторинг проекта; доработка планов.
Разработка	Разработка программного кода и инфраструктуры; документирование конфигураций.
Удовлетворение потребителя	Обучение; доработка плана обучения; тестирование удобства эксплуатации (usability testing); графический дизайн.
Тестирование	Функциональное тестирование; выявление проблем; тестирование документации; доработка плана тестирования.
Управление выпуском	Чеклисты развертывания (rollout checklists); доработка планов внедрения (включая пилотное внедрение); чеклисты подготовки к внедрению (site preparation checklists).

Рекомендуемые промежуточные вехи

Концепция подтверждена

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

Билд n завершен, билд n+1 завершен...

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

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

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

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

Фаза стабилизации

Введение

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

Обычно в начале фазы стабилизации скорость выявления ошибок командой тестирования превосходит скорость, с которой эти ошибки могут устраняться командой разработчиков. Невозможно предсказать, сколько ошибок будет найдено и как много времени понадобится на их устранение. Однако существует два статистических признака, помогающих проектной группе оценить уровень стабилизации решения. Это точка конвергенции (bug convergence) и точка достижения нуля ошибок (zero bug bounce). Они описываются ниже.

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

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

Фаза стабилизации завершается вехой “Готовность решения утверждена” (Release Readiness Approved). В состоянии, достигнутом к этому моменту, решение уже готово к полному внедрению в производственную среду.

Веха “Готовность решения утверждена”

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

Результаты

Результатами фазы стабилизации являются:

· Окончательный продукт (golden release).

· Документация выпуска (release notes).

· Материалы поддержки решения.

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

· Исходный и исполнимый код приложений.

· Проектная документация.

· Анализ пройденной фазы (milestone review).