В системах управления качеством (СМК) и системах информационных технологий (ИТ) контроль изменений — это процесс (формальный или неформальный [1]) , используемый для обеспечения того, чтобы изменения в продукт или систему вносились контролируемым и скоординированным образом. Это снижает вероятность того, что ненужные изменения будут внесены в систему необдуманно, что приведет к возникновению ошибок в системе или отмене изменений, внесенных другими пользователями программного обеспечения. Цели процедуры контроля изменений обычно включают минимальное нарушение работы служб, сокращение количества операций по возврату и экономически эффективное использование ресурсов, задействованных в реализации изменений. Согласно Институту управления проектами , контроль изменений — это «процесс, при котором изменения в документах, результатах или базовых показателях, связанных с проектом, идентифицируются, документируются, одобряются или отклоняются». [2]
Управление изменениями используется в различных отраслях, в том числе в ИТ, [3] разработке программного обеспечения, [1] фармацевтической промышленности, [4] производстве медицинского оборудования, [5] и других отраслях машиностроения/производства. [6] Для отраслей ИТ и программного обеспечения контроль изменений является важным аспектом более широкой дисциплины управления изменениями . Типичными примерами из компьютерной и сетевой среды являются исправления для программных продуктов, установка новых операционных систем , обновления таблиц сетевой маршрутизации или изменения в системах электропитания, поддерживающих такую инфраструктуру . [1] [3]
Некоторые части ITIL охватывают контроль изменений. [7]
Существует значительное совпадение и путаница между управлением изменениями , управлением конфигурацией и контролем изменений. Приведенное ниже определение еще не интегрировано с определениями других.
Управление изменениями можно описать как набор из шести шагов:
Рассмотрите основные и вспомогательные детали предлагаемого изменения. Это должно включать такие аспекты, как идентификация изменения, его владельца(ов), то, как оно будет доведено до сведения и выполнено, [8] как будет проверен успех, оценка важности изменения, его добавленная стоимость, его соответствие деловым и отраслевым стандартам. и намеченную дату завершения. [3] [9] [10]
Оценка воздействия и риска является следующим важным шагом. Приведет ли предложенный план к исполнению, что что-то пойдет не так? Повлияет ли предложенное изменение на связанные системы? На этом этапе следует учитывать даже незначительные детали. После этого предлагаемому изменению в идеале следует присвоить категорию риска: высокий, средний или низкий риск. Изменение с высоким риском требует множества дополнительных шагов, таких как одобрение руководства и уведомление заинтересованных сторон, тогда как изменение с низким уровнем риска может потребовать только одобрения руководителя проекта и минимальной документации. [3] [9] [10] Если это не предусмотрено планом/объемом, следует выразить желание иметь план отката, особенно для изменений с высоким уровнем риска, которые имеют значительные сценарии наихудшего случая. [3]
Будь то контролер изменений, совет по контролю изменений, руководящий комитет или руководитель проекта, обычно требуется процесс рассмотрения и утверждения. [11] План/объем и оценка воздействия/риска рассматриваются в контексте бизнес-целей, требований и ресурсов. Если, например, считается, что запрос на изменение касается проблемы низкой серьезности и незначительного воздействия, для исправления которой требуются значительные ресурсы, запросу может быть присвоен низкий приоритет или вообще отложен. В случаях, когда запрашивается существенное изменение, но без четкого плана, орган проверки/утверждения может запросить полное экономическое обоснование для дальнейшего анализа. [1] [3] [9] [10]
Если запрос на управление изменениями будет одобрен для дальнейшего продвижения, группа реализации выполнит решение посредством небольшого процесса разработки в средах тестирования или разработки. Это дает команде разработки возможность разрабатывать и вносить поэтапные изменения с помощью модульного и/или регрессионного тестирования . [1] [3] [9] Для изменений с низким уровнем риска мало что потребуется для тестирования и проверки, хотя серьезные изменения потребуют значительного тестирования перед внедрением. [9] Затем они запросят одобрение и запросят время и дату для выполнения этапа реализации. В редких случаях, когда решение невозможно протестировать, особое внимание следует уделить окну внесения изменений/реализации. [3]
В большинстве случаев для реализации изменения используется специальная группа внедрения, обладающая техническими знаниями, позволяющими быстро внедрить изменение. Команда также должна внедрять изменения не только в соответствии с утвержденным планом, но и в соответствии с организационными стандартами, отраслевыми стандартами и стандартами управления качеством. [9] Процесс внедрения может также потребовать дополнительных обязанностей персонала за пределами группы внедрения, включая заинтересованные стороны [11] , которых могут попросить помочь в устранении неполадок. [3] После реализации команда может также провести анализ после реализации, который будет проводиться на другом собрании заинтересованных сторон или во время процедуры закрытия проекта. [1] [9]
Процесс закрытия может оказаться одним из наиболее сложных и важных этапов контроля изменений. [12] Три основные задачи на этом конечном этапе включают определение того, что проект действительно завершен, оценку «плана проекта в контексте завершения проекта» и предоставление ощутимых доказательств успеха проекта. [12] Если, несмотря на все усилия, что-то пошло не так в процессе контроля изменений, необходимо будет провести вскрытие произошедшего с целью применения извлеченных уроков для будущих изменений. [3]
В отрасли, регулируемой надлежащей производственной практикой , пользователи часто сталкиваются с этой темой. Для понимания этой концепции доступны различные промышленные руководства и комментарии. [13] [14] [15] Как правило, деятельность обычно регулируется одной или несколькими СОП . [16] С точки зрения информационных технологий для клинических испытаний , они руководствовались другим документом Управления по контролю за продуктами и лекарствами США . [17]
{{cite book}}: CS1 maint: отсутствует местоположение издателя ( ссылка )