1.6.Стадия стабилизации в Microsoft Solution Framework
Во время фазы стабилизации производится тестирование разработанного решения. При этом внимание фокусируется на его эксплуатации в реалистичной модели производственной среды. Проектная группа занимается приоритезацией и устранением ошибок, а также подготовкой решения к выпуску [9].
Обычно в начале фазы стабилизации скорость выявления ошибок командой тестирования превосходит скорость, с которой эти ошибки могут устраняться командой разработчиков. Невозможно предсказать, сколько ошибок будет найдено и как много времени понадобится на их устранение. Однако существует два статистических признака, помогающих проектной группе оценить уровень стабилизации решения. Это точка конвергенции и точка достижения нуля ошибок [21].
В точке конвергенции становится заметен существенный прогресс в устранении ошибок, то есть скорость устранения ошибок начинает превосходить скорость их обнаружения (см. рис. 1.6.).
Поскольку количество найденных, но не устраненных ошибок может колебаться даже после того, как оно начало убывать, конвергенция может рассматриваться скорее, как тенденция, нежели как фиксированный момент во времени. Вслед за этой вехой количество активных ошибок должно продолжать убывать, вплоть до точки достижения нуля. Точка конвергенции дает проектной группе возможность понять, что процесс тестирования близится к концу.
Суть точки конвергенции.
Точка достижения нуля – это момент, когда впервые все выявленные ошибки оказываются устраненными (см. рис. 1.7). Вслед за ней пики количества активных ошибок должны становиться все меньше, вплоть до полного угасания в момент, когда решение уже достаточно стабильно для выпуска первой версии кандидата.
Стоит отметить, что новые ошибки после достижения этой вехи будут проявляться. Однако, точка достижения нуля – это первый момент в работе над проектом, когда команда может отчитаться об отсутствии активных ошибок и сфокусироваться на сохранении этого состояния.
Точка достижения нуля.
После завершения тестирования наступает момент, когда решение «столкнется» с производственной средой, и проектная группа должна как можно тщательнее оттестировать решение до этого момента, – до начала испытания пилотного выпуска.
К вехе «Контрольное тестирование завершено» проектная группа должна:
Оценить результаты тестирования в соответствии с имеющимися критериями успешности.
Подготовить среду внедрения.
Создать необходимые для внедрения процедуры, скрипты и массивы данных.
Иметь готовые учебные материалы.
Обеспечить условия для сопровождения решения.
Создать и протестировать план «отката».
Данная веха может считаться пройденной лишь после обретения проектной группой полной уверенности в готовности и отлаженности всего, что необходимо для внедрения решения.
Как только создана версия, достаточно стабильная для того, чтобы считаться кандидатом для выпуска, производится пилотное внедрение решения [21].
Для пилотной группы подготавливается и выпускается серия версий-кандидатов. Выпуск каждой из них является промежуточной вехой. Эти версии имеют следующие особенности:
Каждая версия-кандидат имеет полный набор составляющих, необходимых для внедрения решения в производство.
Создание версии-кандидата служит тестом готовности решения к выпуску, то есть проверяет готовность всех его составляющих.
Период тестирования, следующий за созданием каждой версии-кандидата, определяет, пригодна ли созданная версия к внедрению, или же проектная группа должна подготовить новую версию-кандидат, исправляющую недостатки предыдущей.
Тестирование версий-кандидатов, проходящее внутри проектной группы, требует высокой степени концентрации и интенсивности работы и фокусируется на выявлении критических «накладок».
Тестирование сопряжено с процессом приоритезации всех нововыявленных ошибок, необходимым для организации их устранения.
Маловероятно, что первая версия-кандидат окажется заключительной. Как правило, при интенсивном тестировании версий-кандидатов будут выявлены «накладки».
Проектная группа тестирует решение целиком в среде, максимально приближенной к производственным условиям. В MSF пилотный релиз – это внедрение решения в часть производственной среды или для части пользователей. В зависимости от проекта, пилотный релиз может принимать различные формы.
На предприятии это может быть релиз для группы пользователей или подмножества серверов данных.
Для веб-разработки это может быть хостинг на тестовых серверах или в подкаталогах, которые доступны в Интернет только через тестовый веб-адрес.
Производители коммерческого программного обеспечения часто выпускают новый программный продукт для специальной группы «первоиспытателей» до того, как будет создана окончательная его версия.
Общим для всех этих форм предварительно выпуска является максимальное приближение тестирования к реальным условиям.
Веха «Пилотное внедрение завершено» может считаться пройденной, когда проектная группа удостоверилась окончательно, что созданное решение жизнеспособно в производственной среде, и каждая его компонента готова к внедрению. В дополнение к этому должно быть осуществлено следующее:
Перед выпуском пилотной версии ее испытатели и проектная группа должны выработать четкие критерии успеха пилотного внедрения. Они должны соответствовать общим критериям успеха разработки.
Все выявленные проблемы должны быть улажены либо доработкой кода, либо документированием обходных путей для персонала внедрения и сопровождения, либо же включением соответствующего материала в сопроводительные руководства и учебные курсы.
К моменту начала работы пилотной версии должна быть создана инфраструктура сопровождения. Это может потребовать обучения персонала сопровождения. Процедуры разрешения проблем пилотной версии могут сильно отличаться от тех, что будут использоваться во время окончательного внедрения и полноценной эксплуатации решения.
Чтобы проверить работоспособность процесса внедрения, необходимо провести пробное испытание для каждого из его элементов. Это поможет заблаговременно выявить трудности внедрения.
Как только в результате пилотного внедрения накоплено и проанализировано достаточное количество данных, проектной группе необходимо принять решение о дальнейших действиях. Возможны следующие варианты:
Шаг вперед: пилотное внедрение нового релиза.
Откат назад: выполняется план отката, и пилотная группа возвращается к конфигурациям, существовавшим до пилотного внедрения. Позднее попытка пилотного внедрения будет повторена вновь с более стабильной версией решения.
Приостановка: пилотная версия «замораживается».
Исправление и продолжение: пилотная группа получает «заплату» к существующему коду.
Стоит отметить, что начиная с фазы разработки и на протяжении фазы стабилизации производятся тестирование приемлемости для потребителей и исследование эргономичности. Их цель – убедиться в том, что новая система отвечает требованиям потребителей и бизнеса.
По достижению вехи «Тестирование приемлемости для потребителей завершено» пользователи осуществляют тестирование и одобряют работу решения в непроизводственной среде. Это включает в себя проверку интеграции системы с работающими в производственной среде бизнес приложениями. Также должны быть проверены разработанные процедуры «отката» и восстановления после сбоев.
После одобрения менеджерами выпуска, разработанное программное обеспечение и все докупленные к нему компоненты переносятся из архива группы разработки в архив группы сопровождения.
Тестирование потребительских качеств дает персоналу сопровождения и пользователям возможность понять и испытать новую технологию на практике. Этот процесс помогает выявить аспекты, в которых у пользователей возникают трудности. Также тестирование позволяет менеджерам выпуска выявить проблемы, которые могут помешать успешному внедрению решения.
Фаза стабилизации завершается вехой «Готовность решения утверждена». К моменту наступления этой вехи проектная группа завершает разрешение всех существенных проблем и производится выпуск или внедрение решения. Ответственность за непрерывное управление и поддержку решения формально переходит от проектной группы к командам сопровождения.
|
