Оформите библиографическое описание источников 53 страница

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

Методология разработки изменений

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

Стандартные изменения представляют собой повторно осуществляемые изменения, связанные с небольшим риском, поэтому они не проходят через фазу разработки. Для изменений других типов выбор методологии, используемой в стадии разработки изменения, является открытым и существует много подобных методологий. При этом могут осуществляться либо простые шаги методологии разработки изменения, либо применяться процесс разработки, используемый внутри самой организации. Кроме того, для структуризации разработки изменения может использоваться модель процессов из подхода к решениям Microsoft (Microsoft Solutions Framework — MSF), которая показана на рис. 8. Более подробную информацию об MSF можно найти по адресу http://www.microsoft.com/MSF.

Рис. 8. Модель процесса MSF

Выбранная методология разработки должна быть достаточно гибкой для того, чтобы с ее помощью можно было обеспечить проведение работ по разработке любого объема. Например, неформально можно отметить, что с использованием MSF можно даже осуществить такую работу, как внесение поправок в документ с описанием процесса, который проходит через процедуры управления изменениями. В этом случае фазы прогнозирования и планирования являются очень короткими и не требуют участия большого количества людей. А для фазы разработки не требуется сложный план проекта, поскольку исправление документа сводится в основном к работе над текстом и может потребовать привлечения только одного или двух человек. С другой стороны, сложное изменение, такое как обновление операционных систем всех настроенных компьютеров с переходом на Microsoft Windows® XP, — это очень большой проект, предусматривающий участие большого количества людей во всей организации, требующий проведения продолжительных этапов планирования и разработки и оцениваемый крупными денежными затратами. В подобных случаях необходимо придерживаться формальной методологии разработки, для того чтобы менеджер изменений мог отслеживать ход работ по внесению изменений и координировать любые сдвиги в запланированных сроках развертывания с другими изменениями.

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

Примечание В фазе разработки и особенно во время оценки промежуточных этапов (как описано ниже), группа проектировщиков может отказаться от идее внести данное изменение. Это может случиться по многим причинам. Например, в фазе прогнозирования может обнаружиться, что отсутствуют достаточные возможности бюджета для реализации изменения в желаемом объеме; еще один вариант состоит в том, что в фазе разработки изменение может стать устаревшим из-за таких событий, как слияние компаний. На блок-схемах подобные точки принятия решений не показаны в целях упрощения. Но если необходимо отказаться от изменения, то этот вопрос следует обсудить на очередном совещании CAB и в случае необходимости закрыть данный RFC. Менеджер изменений указывает причину отказа от изменения в журнале изменений, а также сообщает об этом инициатору изменения и другим заинтересованным сторонам.

Оценка промежуточных этапов

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

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

Дата добавления: 2015-01-04