Тема
7. Методология MSF.
Фазы разработки и стабилизации
1.
Вспоминая предыдущую лекцию
2.
Разработка решения. Фаза разработки
3.
Стабилизация решения. Фаза стабилизации
4.
Внедрение решения. Фаза внедрения
5.
Литература
Вспоминая предыдущую лекцию
Наша предыдущая лекция была посвящена фазам
выработки концепции и планирования в MSF.
Для каждой фазы мы рассмотрели:
§ Основные
задачи фазы
§ Задачи ролевых
групп
§ Вехи фазы
§ Результаты
фазы
Также обсудили учебный пример применительно к
действиям, которые должны выполняться в течение указанных фаз.
Разработка
решения. Фаза разработки
Основные задачи фазы
На фазе разработки проектная группа фокусируется
на создании компонент решения (включая как документацию, так и программный
код). Однако некоторая часть этой работы может продолжаться также на фазе
стабилизации, если такая необходимость выявлена в процессе тестирования. Данная
фаза также включает в себя разработку инфраструктуры.
Следует обратить внимание, что активность
проектной команды на этом этапе не ограничивается написанием разработчиками
кода – все ролевые кластеры принимают деятельное участие в создании и
тестировании решения.
Задачи ролевых групп на фазе
разработки
Основные задачи и сферы ответственности каждого из
ролевых кластеров проектной группы во время фазы разработки рассмотрим в виде
таблицы.
|
Ролевой кластер |
Задачи |
|
Управление продуктом |
Ожидания заказчика. |
|
Управление программой |
Управление
функциональной спецификацией; мониторинг проекта; доработка планов. |
|
Разработка |
Разработка
программного кода и инфраструктуры; документирование конфигураций. |
|
Удовлетворение потребителя |
Обучение;
доработка плана обучения; тестирование удобства эксплуатации (usability testing); графический дизайн. |
|
Тестирование |
Функциональное
тестирование; выявление проблем; тестирование документации; доработка плана тестирования. |
|
Управление выпуском |
Чеклисты
развертывания (rollout checklists); доработка планов внедрения (включая пилотное
внедрение); чеклисты подготовки к внедрению (site
preparation checklists). |
Вехи фазы разработки
Веха “Разработка завершена” является кульминацией
фазы разработки. К моменту ее наступления создание всех составляющих завершено,
и решение готово к тестированию и стабилизации. Заказчики, потребители,
персонал сопровождения и другие заинтересованные стороны получают возможность
оценить решение и выявить все оставшиеся проблемы и неурегулированные вопросы,
которые должны быть улажены до выпуска решения.
В течение фазы MSF рекомендует
выделить промежуточные вехи:
§ Концепция
подтверждена
Подтверждение
концепции (proof of concept) включает в себя
проверку ключевых элементов решения в непроизводственной копии существующей
среды. Проектная группа демонстрирует группе сопровождения и потребителям все
аспекты решения с целью верификации сформулированных требований.
§ Билд n
завершен, билд n+1 завершен...
Поскольку
центром внимания фазы разработки является создание решения, проектной группе
необходимо установить промежуточные вехи, помогающие определить прогресс в этой
работе.
Разработка
ведется параллельно и сегментировано, поэтому возникает потребность в единой
мере общего прогресса. Промежуточные билды предоставляют такую меру, заставляя
команду разработчиков синхронизировать различные составляющие на уровне решения
в целом.
В зависимости
от проекта, количество промежуточных билдов и частота их создания может
меняться.
Зачастую имеет
смысл устанавливать вехи завершения (фиксации) графического дизайна и
разработки базы данных, так как от этих составляющих зависит очень многое.
Результаты фазы разработки
Результатами фазы разработки являются:
§ Исходный и
исполнимый код приложений.
§ Скрипты
установки и конфигурирования.
§ Окончательная
функциональная спецификация.
§ Материалы
поддержки решения.
§ Спецификации и
сценарии тестов.
Стабилизация
решения. Фаза стабилизации
Основные задачи фазы
Во время фазы стабилизации производится
тестирование разработанного решения. При этом внимание фокусируется на его
эксплуатации в реалистичной модели производственной среды. Проектная группа
занимается приоритезацией и устранением ошибок, а также подготовкой решения к
выпуску.
Обычно в начале фазы стабилизации скорость
выявления ошибок командой тестирования превосходит скорость, с которой эти
ошибки могут устраняться командой разработчиков. Невозможно предсказать,
сколько ошибок будет найдено и как много времени понадобится на их устранение.
Однако существует два статистических признака, помогающих проектной группе
оценить уровень стабилизации решения. Это точка конвергенции (bug
convergence) и точка достижения нуля ошибок (zero
bug bounce). Они описываются ниже.
MSF не использует для описания состояния проекта
термины “альфа” и “бета”. Хотя эти понятия применяются довольно часто, их
интерпретация далеко не однозначна. При желании проектная группа может их
использовать, но при этом они должны быть четко определены и понятны как членам
проектной группы, так и заказчику и другим заинтересованным сторонам.
Как только создана версия, достаточно стабильная
для того, чтобы считаться кандидатом для выпуска, производится пилотное
внедрение решения.
Задачи ролевых групп на фазе
стабилизации
Основные задачи и сферы ответственности каждого из
ролевых кластеров проектной группы во время фазы стабилизации рассмотрим в виде
таблицы.
|
Ролевой кластер |
Задачи |
|
Управление продуктом |
Исполнение
коммуникационного плана; планирование премьеры продукта. |
|
Управление программой |
Мониторинг
проекта; приоритезация ошибок. |
|
Разработка |
Устранение
ошибок; оптимизация программного кода. |
|
Удовлетворение потребителя |
Доработка
эксплуатационных руководств; учебные материалы. |
|
Тестирование |
Тестирование;
сообщение об ошибках и их статусе; тестирование конфигурации. |
|
Управление выпуском |
Развертывание
и поддержка пилотного внедрения; планирование внедрения; обучение персонала
сопровождения. |
Вехи фазы стабилизации
Фаза стабилизации завершается вехой “Готовность
решения утверждена” (release readiness approved).
В состоянии, достигнутом к этому моменту, решение уже готово к полному
внедрению в производственную среду.
К моменту наступления этой вехи проектная группа
завершает разрешение всех существенных проблем и происходит выпуск или
внедрение решения. Ответственность за непрерывное управление и поддержку
решения формально переходит от проектной группы к командам сопровождения.
В течение фазы MSF рекомендует
выделить промежуточные вехи:
§ Точка
конвергенции
В точке
конвергенции (bug convergence) становится заметен
существенный прогресс в устранении ошибок, то есть скорость устранения ошибок
начинает превосходить скорость их обнаружения.
Рис. 8.1. Точка конвергенции.
Поскольку
количество найденных, но не устраненных ошибок может колебаться даже после
того, как оно начало убывать, конвергенция может рассматриваться скорее как
тенденция, нежели как фиксированный момент во времени. Вслед за этой вехой
количество активных ошибок должно продолжать убывать, вплоть до точки
достижения нуля. Точка конвергенции дает проектной группе возможность понять,
что процесс тестирования близится к концу.
§ Точка
достижения нуля (zero-bug bounce)
Это момент,
когда впервые все выявленные ошибки оказываются устраненными. Вслед за ней пики
количества активных ошибок должны становиться все меньше, вплоть до полного
угасания в момент, когда решение уже достаточно стабильно для выпуска первой
версии кандидата.
Рис. 8.2. Точка достижения нуля.
Существенную
роль играет тщательная приоритезация ошибок, поскольку устранение всякой из них
содержит риск внесения новых ошибок. Точка достижения нуля ясно показывает, что
проектная группа приближается к созданию стабильной версии кандидата (release
candidate).
Заметим, что
новые ошибки после достижения этой вехи наверняка будут найдены. Однако точка
достижения нуля – это первый момент в работе над проектом, когда команда может
честно отчитаться об отсутствии активных ошибок и сфокусироваться на сохранении
этого состояния.
§ Версии-кандидаты
Для пилотной
группы подготавливается и выпускается серия версий-кандидатов. Выпуск каждой из
них является промежуточной вехой. Эти версии имеют следующие особенности:
o
Каждая
версия-кандидат имеет полный набор составляющих, необходимых для внедрения
решения в производство.
o
Создание
версии-кандидата служит тестом готовности решения к выпуску, то есть проверяет
готовность всех его составляющих.
o
Период
тестирования, следующий за созданием каждой версии-кандидата, определяет,
пригодна ли созданная версия к внедрению, или же проектная группа должна
подготовить новую версию-кандидат, исправляющую недостатки предыдущей.
o
Тестирование
версий-кандидатов, проходящее внутри проектной группы, требует высокой степени
концентрации и интенсивности работы.
o
Маловероятно,
что первая версия-кандидат окажется заключительной.
§ Контрольное
тестирование завершено (pre-production test complete)
Суть этой
промежуточной вехи заключается в подготовке к пилотному выпуску решения. Данная
веха очень важна, поскольку наступает момент, когда решение “столкнется” с
производственной средой, и проектная группа должна как можно тщательнее
оттестировать решение до этого момента, – до начала испытания пилотного
выпуска.
К данной вехе
проектная группа должна:
ü Оценить
результаты тестирования в соответствии с имеющимися критериями успешности.
ü Подготовить
среду внедрения.
ü Создать
необходимые для внедрения процедуры, скрипты, массивы данных.
ü Иметь готовые
учебные материалы.
ü Обеспечить
условия для сопровождения решения.
ü Создать и
протестировать план “отката” (rollback plan).
Данная веха
может считаться пройденной лишь после обретения проектной группой полной
уверенности в готовности всего, что необходимо для внедрения решения.
§ Тестирование
приемлемости для потребителей завершено
Тестирование
приемлемости для потребителей (user acceptance testing)
и исследование эргономичности (usability studies)
выполняются начиная с фазы разработки и продолжаются на протяжении фазы
стабилизации. Их цель – убедиться в том, что новая система отвечает требованиям
потребителей и бизнеса.
По достижению
данной вехи пользователи осуществляют тестирование и одобряют работу решения в
непроизводственной среде (non-production environment).
Это включает в себя проверку интеграции системы с работающими в
производственной среде бизнес приложениями. Также должны быть проверены разработанные
процедуры “отката” и восстановления после сбоев (rollout
and backout procedures).
После
одобрения менеджерами выпуска, разработанное программное обеспечение и все
докупленные к нему компоненты переносятся из архива группы разработки в архив
группы сопровождения.
§ Пилотное
внедрение завершено
Во время этой
промежуточной вехи проектная группа тестирует решение целиком в среде,
максимально приближенной к производственным условиям. В MSF пилотный релиз (pilot
release) – это внедрение решения в часть производственной среды
или для части пользователей. В зависимости от проекта, пилотный релиз может
принимать различные формы.
ü На предприятии
это может быть релиз для группы пользователей или подмножества серверов данных.
ü Для
веб-разработки это может быть хостинг на тестовых серверах или в подкаталогах,
которые доступны в Internet только через тестовый веб-адрес.
ü Производители
коммерческого программного обеспечения, такие как Microsoft, часто выпускают новый программный продукт для
специальной группы “первоиспытателей” до того, как будет создана окончательная
его версия.
Общим для всех
этих форм предварительно выпуска является максимальное приближение тестирования
к реальным условиям.
Веха “Пилотное
внедрение завершено” не может считаться пройденной, пока проектная группа не
удостоверилась окончательно, что созданное решение жизнеспособно в
производственной среде, и каждая его компонента готова к внедрению.
Как только в
результате пилотного внедрения накоплено и проанализировано достаточное
количество данных, проектной группе необходимо принять решение о дальнейших
действиях. Возможны следующие варианты:
ü Шаг вперед:
пилотное внедрение нового релиза.
ü Откат назад:
выполняется план отката, и пилотная группа возвращается к конфигурациям,
существовавшим до пилотного внедрения. Позднее попытка пилотного внедрения
будет повторена вновь с более стабильной версией решения.
ü Приостановка:
пилотная версия “замораживается”.
ü Исправление и
продолжение: пилотная группа получает “заплатку” (patch)
к существующему коду.
ü Переход к фазе
внедрения.
Результаты фазы стабилизации
Результатами фазы стабилизации являются:
§ Окончательный
продукт (golden release).
§ Документация
выпуска (release notes).
§ Материалы
поддержки решения.
§ Результаты и
инструментарий тестирования.
§ Исходный и исполнимый
код приложений.
§ Проектная
документация.
§ Анализ
пройденной фазы (milestone review).
Внедрение
решения. Фаза внедрения
Основные задачи фазы
Во время этой фазы проектная группа внедряет
технологии и компоненты решения, стабилизирует внедренное решение, передает
работу персоналу поддержки и сопровождения и получает со стороны заказчика
окончательное одобрение результатов проекта. По завершению внедрения проектная
группа производит анализ выполненной работы и удовлетворенности заказчика.
Во время этой фазы по ходу переноса компонент
решения из среды тестирования в производственную среду могут продолжаться меры
по стабилизации решения.
Задачи ролевых групп на фазе
внедрения
Основные задачи и сферы ответственности каждого из
ролевых кластеров проектной группы во время фазы внедрения рассмотрим в виде
таблицы.
|
Ролевой кластер |
Задачи |
|
Управление продуктом |
Получение
отзывов и оценок заказчика; акт о приеме выполненной работы. |
|
Управление программой |
Сопоставление
рамок проекта с поставленным решением; управление стабилизацией. |
|
Разработка |
Разрешение
проблем; поддержка эскалации. |
|
Удовлетворение потребителя |
Обучение;
управление календарным графиком обучения. |
|
Тестирование |
Тестирование
производительности. |
|
Управление выпуском |
Управление
внедрением; одобрение изменений. |
Вехи фазы внедрения
Главная веха фазы: “Внедрение завершено”. Данная
веха – кульминация фазы внедрения. К этому времени решение должно начать давать
заказчику ожидаемую бизнес-отдачу, а проектная группа – свернуть свою
деятельность.
Прежде чем считать решение запущенным в
эксплуатацию и свернуть проект, проектная группа должна получить от заказчика
подтверждение того, что его цели достигнуты. Для этого решение должно быть
стабильным и четко удовлетворять выработанным критериям успешности.
Стабильность решения означает также готовность систем его эксплуатации и
сопровождения.
В течение фазы MSF рекомендует
выделить промежуточные вехи:
§ Ключевые
компоненты развернуты (core components deployed).
Большинство
инфраструктурных решений включают в себя ряд компонент, образующих основу всего
решения. С точки зрения отдельных пользователей, сами эти компоненты не имеют
самостоятельной ценности. Однако внедрение полного решения зависит от ключевых
компонент. Кроме того:
ü Компоненты
могут обеспечивать функционирование ключевых технологий внедряемого решения.
Например, это могут быть контроллеры доменов, маршрутизаторы, почтовые серверы,
удаленные серверы доступа, серверы баз данных. Внедрение на местах может
зависеть от этих технологий. При этом может быть необходимым внедрение ключевых
технологий до внедрения всего решения или параллельно с его внедрением на
местах.
ü Для
предотвращения задержек, ключевые компоненты могут быть рассмотрены и
утверждены к внедрению еще до того, как другие части решения стабилизированы.
При этом персонал сопровождения должен быть уверен в надежности ключевых
компонент.
§ Внедрение на
местах завершено (site deployments complete)
К моменту
прохождения этой вехи все целевые потребители получают доступ к решению. Лица,
ответственные за участки внедрения, подписывают акты о пуске решения в
эксплуатацию, хотя определенные проблемы все еще могут возникать.
На этом этапе
проектная группа концентрируется на завершении мероприятий по внедрению и на
сворачивании проекта.
Многие
проекты, в особенности веб-разработки, не подразумевают внедрения на местах,
поэтому данная веха к ним не применима.
§ Внедренное
решение стабилизировано
К моменту этой
вехи заказчик и проектная группа приходят к соглашению о том, что решение
функционирует правильно. Однако нужно понимать, что все еще могут возникать
некоторые проблемы на местах. Они должны отслеживаться и разрешаться. Тем не
менее, проектной группе важно четко зафиксировать точку завершения внедрения, а
не пытаться достичь идеального состояния решения.
Если заказчик
ожидает, что члены проектной команды будут участвовать в поддержке и
сопровождении решения, после завершения проекта соответствующие сотрудники
должны быть переведены на новые роли в структуре сопровождения.
На этой
стадии, по всей вероятности, члены проектной группы и внешние заинтересованные
лица начнут выходить из проекта.
Частью выхода
из проекта является передача функций эксплуатации и сопровождения решения
постоянному персоналу. Во многих случаях для этого уже будут нужные ресурсы. В
других ситуациях может понадобиться разработка новой системы поддержки.
Учитывая объемность такой задачи, разумно рассматривать ее как отдельный
проект.
Результаты фазы внедрения
Результаты фазы внедрения включают в себя:
§
Информационные
системы эксплуатации и поддержки.
§
Процедуры
и процессы.
§
Базы
знаний, отчеты, журналы протоколов.
§
Версии
проектных документов, массивы данных и программный код, разработанные во время
проекта.
§
Отчет
о завершении проекта (project close-out report).
§
Окончательные
версии всех проектных документов.
§
Показатели
удовлетворенности заказчика и потребителей.
§
Описание
последующих шагов.
Литература
1.
Модель
процессов MSF. Белая книга, 2003, перевод eLine Software.
2.
1846A:
Microsoft Solutions Framework Essentials. Microsoft Official Course, 2002
3.
2710B:
Analyzing Requirements and Defining Microsoft .NET Solutions Architecture.
Microsoft Official Course, 2003
4.
MSF Process
Model. White paper, 2002 Microsoft Corporation.
5.
MSF Team
Model. White paper, 2002 Microsoft Corporation.
6.
http://www.microsoft.com/msf
8. MSF for Agile Software Development Process Guidance: [http://go.microsoft.com/fwlink/?linkid=63524]