4.7. "Рекомендации по решению проблемы 2000 года в информационных системах Банка России" (утв. Банком России)

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

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

Проблемы

Контроль изменений исходных кодов, производимых вне проекта 2000 года.

Может остаться неизвестной одновременная работа над программами, что приводит к перезаписи кода или несанкционированным изменениям.

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

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

Обновленные приложения сбоят после развертывания или являются причиной сбоев зависимых приложений.

Возможное влияние на план внедрения.

Изменения могут увеличить затраты. Финансирование затрат на изменение может быть ограниченным и доступным только в определенные промежутки времени.

Рекомендуемый подход

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

Осознание изменения

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

Представление заявки на изменение

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

- план обновления;

- размер изменения;

- вопросы регрессионного тестирования.

Оценивание разработчиками

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

Оценивание управления изменениями

До реализации должен состояться эффективный процесс исследования. Для этого необходимо:

- убедиться, что технические инспекции были выполнены адекватным образом;

- убедиться, что пакет изменения полон и готов для реализации;

- убедиться, что все необходимые внешние утверждения были получены;

- предпринять соответствующее действие утверждения, основанное на этих проверках.

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

В случае утверждения изменения производятся модификация, тестирование и внедрение, а в противном случае оформляется отклонение заявки на изменение.

Отклонение заявки на изменение

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

Модификация

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

Тестирование

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

Внедрение

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

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

Советы

Механизм управления изменениями должен обеспечивать следующее:

- текущую информацию о влиянии и конфигурации в режиме он - лайн, давая разработчику возможность знать воздействие изменения в начале процесса;

- информацию об изменении в режиме он - лайн в течение изменения. Это поможет в процессе планирования и поможет гарантировать, что все требуемые части включены в процесс корректировки;

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

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

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

Используйте самую высокую степень экономически эффективной автоматизации. Автоматизированные инструментальные средства управления изменениями облегчают этот процесс.

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

Разработайте формальные механизмы управления изменениями для каждой из следующих категорий:

- участие руководства;

- управление проектом;

- контроль исходного кода;

- механизмы тестирования / разработки;

- доставка объектов;

- управление готовностью;

- координация / планирование эксплуатации;

- отслеживание проблем;

- исторический анализ;

- распределенные и интегрированные пакеты управления изменениями;

- объектно - ориентированные пакеты управления изменениями.