Процесс управления запросами на изменение в системной инженерии — это процесс запроса, определения достижимости, планирования, внедрения и оценки изменений в системе . Его основными целями являются поддержка обработки и прослеживаемости изменений во взаимосвязанном наборе факторов. [1]
Существует значительное совпадение и путаница между управлением запросами на изменение, контролем изменений и управлением конфигурацией . Определение ниже пока не объединяет эти области.
Управление запросами на изменение было принято за его способность приносить пользу путем улучшения затронутой системы и тем самым удовлетворять «потребности клиентов», но также подвергалось критике за его потенциал запутывать и без необходимости усложнять администрирование изменений. В некоторых случаях, особенно в области информационных технологий , больше средств и работы вкладывается в обслуживание системы (и управление запросами на изменение), чем в первоначальное создание системы. [2] Типичные инвестиции организаций во время первоначального внедрения крупных систем ERP составляют от 15 до 20 процентов от общего бюджета.
В том же ключе Хинли [3] описывает два закона Лемана об эволюции программного обеспечения :
Управление запросами на изменение также имеет большое значение в сфере производства, которая сталкивается со многими изменениями из-за растущей и всемирной конкуренции , технологических достижений и требовательных клиентов. [4] Поскольку многие системы имеют тенденцию меняться и развиваться по мере их использования, проблемы этих отраслей в той или иной степени ощущаются и во многих других.
Примечания: В описанном ниже процессе можно утверждать, что комитет по изменениям должен отвечать не только за решения о принятии/отклонении, но и за расстановку приоритетов, которая влияет на то, как запросы на изменения группируются для обработки.
Для описания процесса управления запросами на изменение используется метод метамоделирования . На рисунке 1 представлена диаграмма процесса-данных , которая поясняется в этом разделе.
Существует шесть основных видов деятельности, которые совместно формируют процесс управления запросами на изменение. Это: определение потенциального изменения, анализ запроса на изменение, оценка изменения, планирование изменения, реализация изменения и рассмотрение и закрытие изменения. Эти виды деятельности выполняются четырьмя различными ролями , которые обсуждаются в Таблице 1. Сами виды деятельности (или их подвиды деятельности, если применимо) описаны в Таблице 2.
Помимо действий, диаграмма процесса-данных (рисунок 1) также показывает результаты каждого действия, т.е. данные. Эти результаты или концепции описаны в таблице 3; в этом контексте наиболее важными концепциями являются: ЗАПРОС НА ИЗМЕНЕНИЕ и ЗАПИСЬ В ЖУРНАЛЕ ИЗМЕНЕНИЙ.
Несколько концепций определены автором (т. е. не имеют ссылок), поскольку либо не удалось найти (хороших) определений, либо они являются очевидным результатом деятельности. Эти концепции отмечены звездочкой ('*'). Свойства концепций были исключены из модели, поскольку большинство из них тривиальны, и в противном случае диаграмма могла бы быстро стать слишком сложной. Кроме того, некоторые концепции (например, ЗАПРОС НА ИЗМЕНЕНИЕ, ВЫПУСК СИСТЕМЫ) подходят для подхода к управлению версиями , предложенного Weerd [6] , но он также был исключен из-за ограничений сложности диаграммы.
Помимо просто «изменений», можно также различать отклонения и отказы. [7] Отклонение — это разрешение (или запрос на это) отступить от требования элемента до его создания. Отказ по сути то же самое, но во время или после создания элемента. Эти два подхода можно рассматривать как минималистское управление запросами на изменение (т. е. отсутствие реального решения рассматриваемой проблемы).
Хороший пример процесса управления запросами на изменение в действии можно найти в разработке программного обеспечения . Часто пользователи сообщают об ошибках или желают получить новые функциональные возможности от своих программ, что приводит к запросу на изменение . Затем компания-разработчик программного обеспечения изучает техническую и экономическую осуществимость внедрения этого изменения и, следовательно, решает, будет ли изменение фактически реализовано. Если это действительно так, изменение должно быть запланировано, например, с помощью функциональных точек . Фактическое выполнение изменения приводит к созданию и/или изменению программного кода , и когда это изменение распространяется, оно, вероятно, вызывает изменение других фрагментов кода. После того, как результаты начального тестирования кажутся удовлетворительными, документация может быть обновлена и выпущена вместе с программным обеспечением. Наконец, менеджер проекта проверяет изменение и закрывает эту запись в журнале изменений.
Другой типичной областью управления запросами на изменение в том виде, в котором она рассматривается здесь, является производственная область. Возьмем, к примеру, проектирование и производство автомобиля . Если, например, будет обнаружено, что подушки безопасности транспортного средства автоматически наполняются воздухом после поездки на большие расстояния, это, несомненно, приведет к жалобам клиентов (или, с большой долей вероятности, к отчетам о проблемах на этапе тестирования). В свою очередь, это приведет к запросу на изменение (см. Рисунок 2 справа), который, вероятно, оправдает изменение. Тем не менее, необходимо провести — скорее всего, упрощенный — анализ затрат и выгод, после которого запрос на изменение может быть одобрен. После анализа влияния на конструкцию автомобиля и графики производства может быть создан план внедрения изменения. Согласно этому плану, изменение может быть фактически реализовано, после чего новая версия автомобиля, как мы надеемся, будет тщательно протестирована, прежде чем она будет выпущена для публики.
Поскольку сложные процессы могут быть очень чувствительны даже к небольшим изменениям, надлежащее управление изменениями на промышленных технологических предприятиях признано критически важным для безопасности. Недокументированные, не оцененные должным образом риски изменений являются рецептом катастрофы. Ярким примером этого является взрыв во Фликсборо , где импровизированные изменения, включающие обход ступени в реакторной линии, стали причиной аварии. Изменение не было должным образом продумано, задокументировано и оценено с точки зрения риска, поэтому событие нарушения герметичности не было идентифицировано. [8] В США OSHA имеет правила, которые регулируют порядок внесения и документирования изменений. Главное требование заключается в том, чтобы тщательный обзор предлагаемого изменения проводился многопрофильной группой, чтобы гарантировать, что используется как можно больше возможных точек зрения для минимизации вероятности пропуска опасности. В этом контексте управление запросами на изменение известно как Управление изменениями, или MOC. Это всего лишь один из многих компонентов Управления безопасностью процессов , раздел 1910.119(l).1.