Управление изменениями (инжиниринг)
Процесс управления запросами на изменения в системной инженерии — это процесс запроса, определения достижимости, планирования, внедрения и оценки изменений в системе . Его основные цели — поддержка обработки и отслеживания изменений взаимосвязанного набора факторов. [1]
Введение
[ редактировать ]Существует значительное совпадение и путаница между управлением запросами на изменения, контролем изменений и управлением конфигурацией . Приведенное ниже определение еще не объединяет эти области.
Управление запросами на изменения получило признание за его способность приносить пользу за счет улучшения затронутой системы и тем самым удовлетворения «потребностей клиентов», но его также критиковали за его способность запутывать и излишне усложнять администрирование изменений. В некоторых случаях, особенно в сфере информационных технологий , на обслуживание системы (и управление запросами на изменения) вкладывается больше средств и труда, чем на первоначальное создание системы. [2] Типичные инвестиции организаций при первоначальном внедрении крупных ERP- систем составляют от 15 до 20 процентов общего бюджета.
В том же духе Хинли [3] описывает два закона Лемана эволюции программного обеспечения :
- Закон продолжающихся изменений : используемые системы должны меняться, иначе они автоматически станут менее полезными.
- Закон возрастающей сложности : в результате изменений структура системы становится все более сложной, и для ее упрощения требуется больше ресурсов.
Управление запросами на изменения также имеет большое значение в сфере производства, которая сталкивается со многими изменениями из-за растущей мировой конкуренции , технологических достижений и требовательных клиентов. [4] Поскольку многие системы имеют тенденцию меняться и развиваться по мере их использования, проблемы этих отраслей в той или иной степени встречаются и во многих других.
Примечания: В описанном ниже процессе можно утверждать, что комитет по изменениям должен нести ответственность не только за принятие/отклонение решений, но и за определение приоритетов, что влияет на то, как запросы на изменения группируются для обработки.
Процесс и его результаты
[ редактировать ]Для описания процесса управления запросами на изменения методика метамоделирования используется . На рисунке 1 изображена диаграмма данных процесса , которая объясняется в этом разделе.
Деятельность
[ редактировать ]Существует шесть основных видов деятельности, которые вместе образуют процесс управления запросами на изменения. Это: определить потенциальные изменения, проанализировать запрос на изменение, оценить изменение, спланировать изменение, внедрить изменение, а также просмотреть и закрыть изменение. Эти действия выполняются четырьмя различными ролями , которые обсуждаются в Таблице 1. Сами действия (или их подвиды деятельности, если применимо) описаны в Таблице 2.
| Роль | Описание |
|---|---|
| Клиент | Клиент — это роль , которая запрашивает изменение из-за возникших проблем или новых требований к функциональности; это может быть физическое лицо или организационная единица, которая может быть внутренней или внешней по отношению к компании, которой поручено реализовать изменение. |
| Руководитель проекта | Менеджер проекта является владельцем проекта , к которому относится ЗАПРОС НА ИЗМЕНЕНИЕ. В некоторых случаях существует отдельный менеджер по изменениям, который в этом случае берет на себя эту роль. |
| Комитет по изменениям | по изменениям Комитет решает, будет ли ЗАПРОС НА ИЗМЕНЕНИЕ реализован или нет. Иногда эту задачу выполняет и руководитель проекта. |
| Изменить конструктор | Разработчик изменений — это человек, который планирует и реализует изменения; можно утверждать, что компонент планирования (частично) берет на себя менеджер проекта. |
| Активность | Подвид деятельности | Описание |
|---|---|---|
| Определите потенциальные изменения | Требуются новые функции [5] | Заказчик желает новый функционал и формулирует ТРЕБОВАНИЕ. |
| Проблема встречи [5] | Клиент сталкивается с проблемой (например, ошибкой ) в системе, что приводит к ОТЧЕТУ О ПРОБЛЕМЕ. | |
| Запросить изменение | Клиент предлагает изменение, создав ЗАПРОС НА ИЗМЕНЕНИЕ. | |
| Анализ запроса на изменение | Определить техническую возможность | Менеджер проекта определяет техническую осуществимость предлагаемого ЗАПРОСА НА ИЗМЕНЕНИЕ, что приводит к ТЕХНИЧЕСКОЙ ВОЗМОЖНОСТИ ИЗМЕНЕНИЯ. |
| Определите затраты и выгоды | Менеджер проекта определяет затраты и выгоды предлагаемого ЗАПРОСА НА ИЗМЕНЕНИЯ, в результате чего определяются ЗАТРАТЫ И ВЫГОДЫ НА ИЗМЕНЕНИЯ. Эту и вышеописанную поддеятельность можно выполнять в любом порядке, и они независимы друг от друга, поэтому моделирование представляет собой неупорядоченную деятельность. | |
| Оцените изменения | На основании ЗАПРОСА НА ИЗМЕНЕНИЕ, ТЕХНИЧЕСКОЙ ВОЗМОЖНОСТИ ИЗМЕНЕНИЯ, а также ЗАТРАТ И ВЫГОД ОТ ИЗМЕНЕНИЯ комитет по изменениям принимает решение о том, можно или нет. Это моделируется как отдельное действие, поскольку это важный этап процесса, и его выполняет другая роль. Он смоделирован как подвид деятельности (без какого-либо содержащего его действия), как рекомендовал Ремко Хелмс (личное общение). | |
| Изменение плана | Анализируйте влияние изменений | Степень изменения (т.е. на какие еще элементы влияет изменение) определяется в ходе АНАЛИЗА ВОЗДЕЙСТВИЯ ИЗМЕНЕНИЙ. Можно утверждать, что это действие приводит к еще одному решению «годен/не годен» или даже является частью действия «Анализ запроса на изменение». Здесь она моделируется как задача планирования для разработчика изменений из-за ее связи с действием «Распространение изменений». |
| Создать планирование | ПЛАН ИЗМЕНЕНИЙ создается для реализации изменений. Некоторые описания процессов (например, Mäkäräinen, 2000) показывают, что также возможно «сохранить» изменения и обработать их позже в пакетном режиме . Эту деятельность можно рассматривать как хороший момент для этого. | |
| Внедрить изменения | Выполнить изменение | Изменение «запрограммировано»; эта деятельность тесно связана с распространением изменений, поскольку иногда изменение необходимо адаптировать и к другим частям системы (или даже к другим системам). |
| Распространение изменений | Изменения, возникающие в результате изменения «Выполнение», должны быть распространены на другие части системы, на которые оно влияет. Поскольку этот и вышеописанный подвиды деятельности сильно зависят друг от друга, они были смоделированы как параллельные действия. | |
| Изменение теста | Разработчик изменений проверяет, действительно ли то, что он создал, работает и удовлетворяет ЗАПРОС НА ИЗМЕНЕНИЕ. Как показано на диаграмме, это может привести к итеративному процессу вместе с двумя вышеуказанными поддействиями. | |
| Обновить документацию | ДОКУМЕНТАЦИЯ обновляется с учетом внесенных изменений. | |
| Изменение выпуска | Опубликован новый РЕЛИЗ СИСТЕМЫ, отражающий внесенные изменения. | |
| Просмотрите и закройте изменение | Подтвердить изменение | Реализация изменения в новом РЕЛИЗЕ СИСТЕМЫ проверяется в последний раз, теперь уже руководителем проекта. Возможно, это должно произойти до релиза, но из-за противоречивых литературных источников и соображений сложности диаграмм было решено смоделировать это таким образом и включить эту проблему. |
| Закрыть изменение | Этот цикл изменений завершен, т.е. ЗАПИСЬ ЖУРНАЛА ИЗМЕНЕНИЙ завершена. |
Результаты
[ редактировать ]Помимо действий, диаграмма данных процесса (рис. 1) также показывает результаты каждого действия, то есть данные. Эти результаты или концепции описаны в Таблице 3; в этом контексте наиболее важными понятиями являются: ЗАПРОС НА ИЗМЕНЕНИЕ и ЗАПИСЬ В ЖУРНАЛЕ ИЗМЕНЕНИЙ.
Некоторые понятия определены автором (т.е. отсутствуют ссылки), поскольку либо не удалось найти (хороших) определений, либо они являются очевидным результатом деятельности. Эти понятия отмечены звездочкой («*»). Свойства понятий были исключены из модели, поскольку большинство из них тривиальны, и в противном случае диаграмма могла бы быстро стать слишком сложной. Более того, некоторые концепции (например, ЗАПРОС НА ИЗМЕНЕНИЕ, ВЫПУСК СИСТЕМЫ) подходят для подхода к управлению версиями , предложенного Weerd, [6] но это также было опущено из-за ограничений сложности диаграммы.
| Концепция | Описание |
|---|---|
| ТРЕБОВАНИЕ | Требуемая функциональность компонента (или предмета; НАСА, 2005). |
| ОТЧЕТ О ПРОБЛЕМЕ | Документ, описывающий проблему, которую не может решить сотрудник службы поддержки 1 уровня; содержит такие элементы, как дата, контактная информация лица, сообщившего о проблеме, причина проблемы, местоположение и описание проблемы, предпринятые действия и их решение, но это не показано на диаграмме (Деннис и др., 2002). |
| ЗАПРОС НА ИЗМЕНЕНИЕ | Документ, описывающий запрошенное изменение и почему это важно; могут возникать из ОТЧЕТОВ О ПРОБЛЕМАХ, усовершенствований системы, других проектов, изменений в базовых системах и высшем руководстве, которые здесь обобщены как ТРЕБОВАНИЯ (Деннис и др., 2002). Важный атрибут: «решение идти/не идти», т.е. будет ли изменение выполнено или нет? |
| ИЗМЕНИТЬ ЗАПИСЬ В ЖУРНАЛЕ* | Отдельная запись в коллекции всех изменений (например, для проекта); состоит из ЗАПРОСА НА ИЗМЕНЕНИЯ, ТЕХНИЧЕСКОЙ ВОЗМОЖНОСТИ ИЗМЕНЕНИЙ, ЗАТРАТ И ПРЕИМУЩЕСТВ ИЗМЕНЕНИЙ, АНАЛИЗА ВОЗДЕЙСТВИЯ ИЗМЕНЕНИЙ, ПЛАНИРОВАНИЯ ИЗМЕНЕНИЙ, ОТЧЕТА ИСПЫТАНИЙ и ПРОВЕРКИ ИЗМЕНЕНИЙ. Не все они должны быть включены, если процесс завершается раньше (т.е. если изменение не реализовано). |
| ИЗМЕНЕНИЕ ТЕХНИЧЕСКОЙ ВОЗМОЖНОСТИ | Концепция, которая указывает, могут ли «надежные аппаратные и программные средства, технические ресурсы, способные удовлетворить потребности предлагаемой системы [т.е. запрос на изменение], быть приобретены или разработаны организацией в требуемое время» (Vogl, 2004). |
| ИЗМЕНЕНИЕ ЗАТРАТ И ВЫГОД | Ожидаемые усилия, необходимые для внедрения, и преимущества (например, экономия средств, увеличение доходов), полученные в результате реализации изменения. Также называется экономической целесообразностью (Vogl, 2004). |
| АНАЛИЗ ВОЗДЕЙСТВИЯ ИЗМЕНЕНИЙ | Оценка степени изменения (Райлич, 1999). |
| ИЗМЕНЕНИЕ ПЛАНИРОВАНИЯ | «Схема, метод или замысел для достижения какой-то цели или достижения чего-либо [т.е. изменения]» (Джорджтаунский университет, без даты), в данном случае изменения. |
| ЭЛЕМЕНТ | «Неспецифический термин, используемый для обозначения любого продукта , включая системы, подсистемы, сборки, подузлы, узлы, комплекты, аксессуары, компьютерные программы, компьютерное программное обеспечение или детали» (Ригби, 2003); имеет (перекрывающиеся) подтипы ДОБАВЛЕННЫЙ ЭЛЕМЕНТ и ИЗМЕНЕННЫЙ ЭЛЕМЕНТ. |
| ДОБАВЛЕННЫЙ ПУНКТ* | Самоочевидно: вновь созданный ЭЛЕМЕНТ; подтип ПУНКТА. |
| ИЗМЕНЕННЫЙ ПУНКТ* | Самоочевидно: ЭЛЕМЕНТ, который уже существовал, но был изменен; подтип ПУНКТА. |
| ОТЧЕТ ИСПЫТАНИЯ | «Документ, описывающий проведение и результаты испытаний, проведенных для системы или компонента [затронутого изменением]» (IEEE, 1991). |
| ДОКУМЕНТАЦИЯ | Согласно определению Библиотеки Университета штата Пенсильвания (2004 г.), ДОКУМЕНТАЦИЯ — это «распечатанный материал, который сопровождает другие материалы (обычно некнижные) и который объясняет, дает инструкции по использованию или иным образом служит руководством к основным материалам. ». В этом контексте это также могут быть цифровые материалы или даже обучение, если оно относится к (частям) системы. |
| ВЫПУСК СИСТЕМЫ | «Товары, выпущенные для продажи или публичного показа» (Принстонский университет, 2003 г.). Состоит из одного или нескольких ПУНКТОВ и сопроводительной ДОКУМЕНТАЦИИ. |
| ПОДТВЕРЖДЕНИЕ ИЗМЕНЕНИЙ | Определение того, соответствует ли результат реализации изменения требованиям, установленным ранее (Ригби, 2003). |
Помимо просто «изменений», можно также выделить отклонения и отказы. [7] Отклонение — это разрешение (или требование об этом) отступить от требования к элементу до его создания. Отказ по сути тот же самый, но чем во время или после создания элемента. Эти два подхода можно рассматривать как минималистическое управление запросами на изменения (т.е. отсутствие реального решения существующей проблемы).
Примеры
[ редактировать ]Хороший пример процесса управления запросами на изменения в действии можно найти в разработке программного обеспечения . Часто пользователи сообщают об ошибках или желают получить новые функциональные возможности своих программ, что приводит к запросу на изменение . Затем компания - разработчик программного обеспечения изучает техническую и экономическую осуществимость внедрения этого изменения и, следовательно, решает, будет ли это изменение действительно реализовано. Если это действительно так, изменения необходимо планировать, например, с помощью функциональных точек . Фактическое выполнение изменения приводит к созданию и/или изменению программного кода , и когда это изменение распространяется, оно, вероятно, приводит к изменению и других фрагментов кода. После того, как первоначальные результаты испытаний кажутся удовлетворительными, документацию можно обновить и выпустить вместе с программным обеспечением. Наконец, руководитель проекта проверяет изменение и закрывает эту запись в журнале изменений.
Еще одна типичная область управления запросами на изменения, как она рассматривается здесь, — это производственная сфера. Возьмем, к примеру, проектирование и производство автомобилей . Если, например, окажется, что подушки безопасности автомобиля автоматически наполняются воздухом после поездки на большие расстояния, это, несомненно, приведет к жалобам клиентов (или, будем надеяться, к сообщениям о проблемах на этапе тестирования). В свою очередь, они создают запрос на изменение (см. рисунок 2 справа), который, вероятно, оправдывает изменение. Тем не менее, необходимо провести – скорее всего, упрощенный – анализ затрат и выгод, после чего запрос на изменение может быть одобрен. После анализа влияния на проектирование автомобилей и графики производства можно составить план внедрения изменений. Согласно этому плану, изменение действительно может быть реализовано, после чего новая версия автомобиля, как мы надеемся, будет тщательно протестирована, прежде чем она будет представлена публике.
На перерабатывающих предприятиях
[ редактировать ]Поскольку сложные процессы могут быть очень чувствительны даже к небольшим изменениям, правильное управление изменениями на промышленных технологических установках признано критически важным для безопасности. Недокументированные изменения, не оцененные должным образом, являются верным путем к катастрофе. Ярким примером этого является взрыв во Фликсборо , где причиной аварии стали импровизированные изменения, связанные с обходом ступени реакторной установки. Изменение не было должным образом продумано, задокументировано и оценено с точки зрения риска, поэтому событие нарушения условий содержания не было выявлено. [8] В США OSHA имеет правила, определяющие порядок внесения и документирования изменений. Основное требование состоит в том, чтобы многопрофильная группа провела тщательный анализ предлагаемого изменения, чтобы гарантировать использование как можно большего количества точек зрения и минимизировать вероятность пропустить опасность. В этом контексте управление запросами на изменения известно как Управление изменениями или MOC. Это лишь один из многих компонентов управления безопасностью процессов , раздел 1910.119(l).1.
См. также
[ редактировать ]- Изменение контроля
- Управление запросами на изменение
- Заказ на инженерное изменение , запрос на изменение
- ПРИНЦ2
- ИТИЛ
- Управление версиями
- Управление релизами
- Жизненный цикл выпуска программного обеспечения
- Управление жизненным циклом приложений
- Системная инженерия
- Система отслеживания проблем
Примечания и ссылки
[ редактировать ]- ^ Црнкович и Перссон-Дальквист (2003).
- ^ Деннис, Уиксом и Тегарден (2002).
- ^ Хинли (1996).
- ^ Хуан и Мак (1999).
- ^ Перейти обратно: а б На самом деле, чтобы получить запрос на изменение, не обязательно одновременно требовать новую функциональность и обнаруживать проблему. Обычно это делает только один из двух. Примерно приближается к этому смыслу моделирование их как неупорядоченных действий. Альтернативой может быть создание двух отдельных «отправных точек» (т.е. начальных состояний), оба указывающих на «Запросить изменение».
- ^ Верд (2006).
- ^ Скотт и Ниссе (2001).
- ^ Маннан (2012).
Справочная литература и дополнительная литература
[ редактировать ]- Црнкович И., Аклунд У. и Перссон-Дальквист А. (2003). Внедрение и интеграция управления данными о продуктах и управления конфигурацией программного обеспечения . Лондон: Артех Хаус.
- Деннис А., Уиксом Б.Х. и Тегарден Д. (2002). Системный анализ и проектирование: объектно-ориентированный подход с использованием UML . Хобокен, Нью-Йорк: John Wiley & Sons, Inc.
- Джорджтаунский университет (nd). Хранилище данных: Глоссарий . Получено 13 апреля 2006 г. по адресу: https://web.archive.org/web/20060423164505/http://uis.georgetown.edu/departments/eets/dw/GLOSSARY0816.html .
- Хинли, DS (1996). Управление эволюцией программного обеспечения: процессно-ориентированная перспектива. Информационные и программные технологии, 38 , 723–730.
- Хуанг, Г.Х. и Мак, КЛ (1999). Текущая практика управления инженерными изменениями в обрабатывающей промышленности Великобритании. Международный журнал операций и управления производством, 19 (1), 21–37.
- ИИЭР (1991). Стандартный словарь терминологии программной инженерии (ANSI) . Институт инженеров по электротехнике и электронике Inc. Получено 13 апреля 2006 г. по адресу: http://www.ee.oulu.fi/research/ouspg/sage/glossary/#reference_6. Архивировано 21 октября 2009 г. в Wayback Machine .
- Мякяряйнен, М. (2000). Процессы управления изменениями программного обеспечения при разработке встроенного программного обеспечения . Кандидатская диссертация. Эспоо: Публикации VTT. Доступно в Интернете: http://www.vtt.fi/inf/pdf/publications/2000/P416.pdf .
- Маннан, Сэм (2012). Предотвращение потерь Лиса в перерабатывающей промышленности (4-е изд.). Оксфорд: Баттерворт-Хайнеманн . ISBN 978-0-12-397189-0 .
- НАСА (2005). Программа данных метрик объектов NASA IV&V — глоссарий и определения . Получено 4 марта 2006 г. по адресу: https://web.archive.org/web/20060307232014/http://mdp.ivv.nasa.gov/mdp_glossary.html .
- Библиотеки Пенсильванского государственного университета (2004 г.). Руководство CCL: Словарь терминов и сокращений . Получено 13 апреля 2006 г. по адресу: https://web.archive.org/web/20060615021317/http://www.libraries.psu.edu/tas/cataloging/ccl/glossary.htm .
- Принстонский университет (2003 г.). ВордНет 2.0 . Получено 13 апреля 2006 г. по адресу: http://dictionary.reference.com/search?q=release .
- Райлих, В. (1999). Изменение и эволюция программного обеспечения. Павелка Дж., Тел Г. и Бартошек М. (ред.), SOFSEM'99, Конспекты лекций по информатике 1725 , 189–202.
- Ригби, К. (2003). Стандарты управления: Словарь терминов . Получено 1 апреля 2006 г. по адресу: https://web.archive.org/web/20060412081603/http://sparc.airtime.co.uk/users/wysywig/gloss.htm .
- Скотт, Дж. А. и Ниссе, Д. (2001). Управление конфигурацией программного обеспечения, Руководство по программной инженерии, свод знаний , глава 7, IEEE Computer Society Press.
- Фогль, Г. (2004). Информационные системы управления: Словарь терминов . Получено 13 апреля 2006 г. с веб-сайта Университета мучеников Уганды: https://web.archive.org/web/20060411160145/http://www.321site.com/greg/courses/mis1/glossary.htm .
- Верд, И. ван де (2006). Техника метамоделирования: Черновой вариант курса «Методическая инженерия» 05/06 . Получено 1 марта 2006 г. по адресу: https://bscw.cs.uu.nl/bscw/bscw.cgi/d1009019/Instructions. [ постоянная мертвая ссылка ] для диаграммы данных процесса.pdf [доступ ограничен].