Назначением данного раздела является определение процедур, которые будут минимизировать влияние на внесение изменений, но позволят продолжить обслуживание способом, который защищает целостность данных и минимизирует нарушение обслуживания.
Управлением изменениями являются разрешение, выполнение и запись изменений. Управление изменениями помогает предотвратить введение ошибок в производственную систему и обеспечить учет (то есть руководитель проекта должен знать, почему было сделано изменение, каким было его влияние на стоимость, план и другие факторы, кто был инициатором изменения и кто согласился делать необходимые изменения).
Контроль изменений исходных кодов, производимых вне проекта 2000 года.
Может остаться неизвестной одновременная работа над программами, что приводит к перезаписи кода или несанкционированным изменениям.
Конфликты в уровнях версий могут происходить из-за ошибок, срочных исправлений или параллельной разработки.
Неточная версия кода может использоваться из-за программистов, вводящих элементы с тем же самым именем или использующих предшествующую версию на секционированном (partitioned) наборе данных.
Обновленные приложения сбоят после развертывания или являются причиной сбоев зависимых приложений.
Возможное влияние на план внедрения.
Изменения могут увеличить затраты. Финансирование затрат на изменение может быть ограниченным и доступным только в определенные промежутки времени.
Процесс управления изменениями, которому необходимо следовать во время преобразования 2000 года, включает следующие этапы.
Изменения могут быть сделаны в техническом обеспечении, программном обеспечении, сопровождении, эксплуатации, документации и временных модификациях. Во время преобразования 2000 года изменение часто происходит в исходном коде, файлах и базах данных, а также интерфейсах пользователя.
Представление заявки на изменение
Все заявки на изменение представляются разработчиком - инициатором для анализа влияния. Разработчик - инициатор должен также рекомендовать, когда заявки на изменение должны быть реализованы, основываясь на следующих критериях:
- вопросы регрессионного тестирования.
Связанные с изменением разработчики будут изучать заявку на изменение и проводить анализ влияния с соответствующим техническим, управленческим персоналом, персоналом обеспечения качества и персоналом пользователей. Анализ влияния включает такие вопросы, как срочность, риск, требования регрессионного тестирования, управление изменениями, план обновления, затраты, надежность и постоянство. Анализ должен быть задокументирован, приложен к соответствующей заявке на изменение и содержать запрошенное изменение, определяющие факторы, альтернативные решения, потенциальное влияние на другие приложения, регрессионные тесты для повторной проверки и изменения в документации пользователя.
Оценивание управления изменениями
До реализации должен состояться эффективный процесс исследования. Для этого необходимо:
- убедиться, что технические инспекции были выполнены адекватным образом;
- убедиться, что пакет изменения полон и готов для реализации;
- убедиться, что все необходимые внешние утверждения были получены;
- предпринять соответствующее действие утверждения, основанное на этих проверках.
Когда согласие не может быть достигнуто, представитель пользователя принимает решения о приоритете работ по удовлетворению требований бизнеса / пользователя и администратор приложения принимает решения, основываясь на технических вопросах, касающихся затрат и приоритетных ограничений.
В случае утверждения изменения производятся модификация, тестирование и внедрение, а в противном случае оформляется отклонение заявки на изменение.
Отклонение заявки на изменение
Заявка на изменение может быть не принята для реализации по одной или более из следующих причин: плана обновления, затрат или постоянства. Разработчик - инициатор должен быть уведомлен об отказе и осведомлен о ходе предпринимаемых действий.
Когда изменение утверждено, разработчик, назначенный на изменение, может проверить элемент конфигурации программного обеспечения и выполнить корректирующее действие. Разработчик отвечает также за ведение записей о произведенных действиях по изменению.
Тестирование необходимо, чтобы определить, что изменение работает правильно и функциональность системы не была нарушена. Изменение не должно вводить ошибки в систему, и измененные приложения должны работать в рамках нового и первоначального диапазонов дат.
Внедряться будут только санкционированные и проверенные изменения. При утверждении более обширных изменений разработчик должен представить на утверждение новый анализ влияния.
После физической реализации изменений, но прежде чем приложение запускается в производство, проводится соответствующее приемо - сдаточное тестирование, чтобы гарантировать, что изменение способно удовлетворить требованиям своего проектирования.
Механизм управления изменениями должен обеспечивать следующее:
- текущую информацию о влиянии и конфигурации в режиме он - лайн, давая разработчику возможность знать воздействие изменения в начале процесса;
- информацию об изменении в режиме он - лайн в течение изменения. Это поможет в процессе планирования и поможет гарантировать, что все требуемые части включены в процесс корректировки;
- уведомление, когда несколько разработчиков пытаются обратиться к модулю. Это защитит от проблемы двух разработчиков, по незнанию решающих различные задачи сопровождения в отношении одного и того же модуля.
Обеспечьте условия для нескольких уровней сопровождения и автоматического уведомления и управления. Это гарантирует, что все участвующие стороны знают о модификациях программы и краткосрочные модификации включены в долгосрочный проект. Программное обеспечение может также содержать возможности запрета параллельной разработки, если изменение не определено как срочное.
База данных управления изменениями может быть полезна в накоплении и отслеживании информации об изменениях.
Используйте самую высокую степень экономически эффективной автоматизации. Автоматизированные инструментальные средства управления изменениями облегчают этот процесс.
Создавайте резервную копию исходного кода до выполнения модификаций. Имейте также проверенную процедуру поиска резервной копии кода. Она будет полезной, когда не проходит тестирование, произошла перезапись кода или когда в исходный код внесены несанкционированные изменения.
Разработайте формальные механизмы управления изменениями для каждой из следующих категорий:
- механизмы тестирования / разработки;
- координация / планирование эксплуатации;
- распределенные и интегрированные пакеты управления изменениями;
- Гражданский кодекс (ГК РФ)
- Жилищный кодекс (ЖК РФ)
- Налоговый кодекс (НК РФ)
- Трудовой кодекс (ТК РФ)
- Уголовный кодекс (УК РФ)
- Бюджетный кодекс (БК РФ)
- Арбитражный процессуальный кодекс
- Конституция РФ
- Земельный кодекс (ЗК РФ)
- Лесной кодекс (ЛК РФ)
- Семейный кодекс (СК РФ)
- Уголовно-исполнительный кодекс
- Уголовно-процессуальный кодекс
- Производственный календарь на 2025 год
- МРОТ 2024
- ФЗ «О банкротстве»
- О защите прав потребителей (ЗОЗПП)
- Об исполнительном производстве
- О персональных данных
- О налогах на имущество физических лиц
- О средствах массовой информации
- Производственный календарь на 2024 год
- Федеральный закон "О полиции" N 3-ФЗ
- Расходы организации ПБУ 10/99
- Минимальный размер оплаты труда (МРОТ)
- Календарь бухгалтера на 2024 год
- Частичная мобилизация: обзор новостей