1. Вспоминая предыдущую лекцию

Наша предыдущая лекция была посвящена фазам выработки концепции и планирования в MSF.

Для каждой фазы мы рассмотрели:

• Основные задачи фазы
• Задачи ролевых групп
• Вехи фазы
• Результаты фазы

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

2. Разработка решения. Фаза разработки

Внимание! Презентации семинаров и шаблоны к ним находятся  здесь.

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

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

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

2.2. Задачи ролевых групп на фазе разработки

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

2.3. Вехи фазы разработки

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

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

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

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

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

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

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

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

2.4. Результаты фазы разработки

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

• Исходный и исполнимый код приложений.
• Скрипты установки и конфигурирования.
• Окончательная функциональная спецификация.
• Материалы поддержки решения.
• Спецификации и сценарии тестов.

3. Стабилизация решения. Фаза стабилизации

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

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

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

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

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