WikiDer > Управление изменениями (инжиниринг)
В управление запросами на изменение процесс в системная инженерия это процесс запроса, определения достижимости, планирования, внедрения и оценки изменений в система. Его основные цели - поддерживать обработку и отслеживаемость изменений взаимосвязанного набора факторов.[1]
Вступление
Существует значительное совпадение и путаница между управлением запросами на изменение, изменить управление и управление конфигурацией. Приведенное ниже определение еще не объединяет эти области.
Управление запросами на изменение приветствовалось за его способность обеспечивать преимущества за счет улучшения затронутой системы и, таким образом, удовлетворения «потребностей клиентов», но также подвергалось критике за то, что оно могло запутать и излишне усложнить администрирование изменений. В некоторых случаях, особенно в Информационные технологии домена, больше средств и работы вкладывается в обслуживание системы (и управление запросами на изменение), чем на первоначальное создание системы.[2] Типичные инвестиции организаций при первоначальном внедрении крупных ERP системы составляет от 15 до 20 процентов от общего бюджета.
В том же духе Хинли [3] описывает два из Законы Лемана эволюции программного обеспечения:
- Закон продолжающихся изменений: Используемые системы должны измениться, иначе они автоматически станут менее полезными.
- Закон возрастающей сложности: Благодаря изменениям структура системы становится все более сложной, и для ее упрощения требуется больше ресурсов.
Управление запросами на изменения также имеет большое значение в области производства, которая сталкивается со многими изменениями из-за роста и во всем мире. конкуренция, технический прогресс и требовательные клиенты.[4] Поскольку многие системы имеют тенденцию меняться и развиваться по мере их использования, проблемы этих отраслей в некоторой степени испытывают и многие другие.
Примечания: В приведенном ниже процессе можно утверждать, что комитет по изменениям должен нести ответственность не только за принятие / отклонение решений, но и за приоритизацию, которая влияет на то, как запросы на изменение группируются для обработки.
Процесс и его результаты
Для описания процесса управления запросами на изменение техника мета-моделирования используется. На рисунке 1 изображен диаграмма данных процесса, что объясняется в этом разделе.
Деятельность
Существует шесть основных действий, которые вместе образуют процесс управления запросами на изменение. К ним относятся: определение потенциального изменения, анализ запроса на изменение, оценка изменения, планирование изменения, реализация изменения и проверка и закрытие изменения. Эти действия выполняются четырьмя разными роли, которые обсуждаются в Таблице 1. Сами мероприятия (или их подвиды деятельности, если применимо) описаны в Таблице 2.
| Роль | Описание |
|---|---|
| Покупатель | В покупатель это роль, которая запрашивает изменение из-за возникших проблем или новых требований к функциональности; это может быть человек или организационная единица, которая может быть внутренней или внешней по отношению к компании, которую просят внести изменения. |
| Руководитель проекта | В руководитель проекта является владельцем проект что касается ЗАПРОСА НА ИЗМЕНЕНИЕ. В некоторых случаях есть отдельный менеджер изменений, который в этом случае берет на себя эту роль. |
| Комитет по изменениям | Перемена комитет решает, будет ли ЗАПРОС НА ИЗМЕНЕНИЕ реализован или нет. Иногда эту задачу выполняет и руководитель проекта. |
| Изменить конструктора | Создатель изменений - это человек, который планирует и внедряет изменения; Можно утверждать, что компонент планирования (частично) берет на себя руководитель проекта. |
| Мероприятия | Подвид деятельности | Описание |
|---|---|---|
| Определите потенциальные изменения | Требовать новую функциональность[5] | Заказчик желает новой функциональности и формулирует ТРЕБОВАНИЕ. |
| Проблема при встрече[5] | Клиент сталкивается с проблемой (например, ошибка) в системе, и это приводит к СООБЩЕНИЮ О ПРОБЛЕМЕ. | |
| Запросить изменение | Клиент предлагает изменение, создав ЗАПРОС НА ИЗМЕНЕНИЕ. | |
| Анализировать запрос на изменение | Определить техническую осуществимость | Менеджер проекта определяет техническую осуществимость предложенного ЗАПРОСА НА ИЗМЕНЕНИЕ, что приводит к ИЗМЕНЕНИЮ ТЕХНИЧЕСКОЙ ОСОБЕННОСТИ. |
| Определите затраты и выгоды | Менеджер проекта определяет затраты и выгоды от предложенного ЗАПРОСА НА ИЗМЕНЕНИЕ, что приводит к ИЗМЕРЕНИЯМ И ВЫГОДам. Это и вышеупомянутое вспомогательное действие можно выполнять в любом порядке, и они не зависят друг от друга, поэтому моделирование является неупорядоченным действием. | |
| Оценить изменение | На основании ЗАПРОСА НА ИЗМЕНЕНИЕ, его ТЕХНИЧЕСКОЙ ОСОБЕННОСТИ ИЗМЕНЕНИЯ, а также ЗАТРАТ И ПРЕИМУЩЕСТВА ИЗМЕНЕНИЯ, комитет по изменениям принимает решение «годен / не годен». Это моделируется как отдельная деятельность, потому что это важный этап процесса, и его выполняет другая роль. Он смоделирован как вспомогательная деятельность (без какой-либо деятельности, содержащей ее) в соответствии с рекомендациями Ремко Хелмса (личное сообщение). | |
| Изменение плана | Анализировать влияние изменений | Степень изменения (то есть, какие другие элементы влияют на изменение) определяется в АНАЛИЗЕ ВОЗДЕЙСТВИЯ ИЗМЕНЕНИЯ. Можно утверждать, что это действие приводит к другому решению «годен / не годен» или что оно даже является частью действия «Анализировать запрос на изменение». Здесь он моделируется как задача планирования для создателя изменений из-за его связи с действием Распространить изменение. |
| Создать планирование | ПЛАНИРОВАНИЕ ИЗМЕНЕНИЙ создается для выполнение изменения. Некоторые описания процессов (например, Mäkäräinen, 2000) показывают, что также возможно «сохранить» изменения и обработать их позже в партия. Это упражнение можно рассматривать как хороший повод для этого. | |
| Внести изменения | Выполнить изменение | Изменение «запрограммировано»; эта деятельность тесно связана с распространением изменений, потому что иногда изменение также необходимо адаптировать к другим частям системы (или даже другим системам). |
| Распространять изменение | Изменения, происходящие в результате выполнения изменения, должны распространяться на другие части системы, на которые оно влияет. Поскольку это и вышеупомянутое вспомогательное действие сильно зависят друг от друга, они были смоделированы как параллельные действия. | |
| Тестовое изменение | Разработчик изменений проверяет, действительно ли то, что он создал, работает и удовлетворяет ЗАПРОС НА ИЗМЕНЕНИЕ. Как показано на диаграмме, это может привести к итеративный процесс вместе с двумя вышеупомянутыми подвидами деятельности. | |
| Обновить документацию | ДОКУМЕНТАЦИЯ обновлена, чтобы отразить внесенные изменения. | |
| Выпуск изменения | Новый ВЫПУСК СИСТЕМЫ, отражающий примененные изменения, становится общедоступным. | |
| Просмотреть и закрыть изменения | Проверить изменение | Внедрение изменений в новом СИСТЕМНОМ РЕЛИЗЕ проверяется в последний раз, теперь уже менеджером проекта. Возможно, это должно произойти до выпуска, но из-за противоречивых литературных источников и соображений сложности диаграммы было выбрано смоделировать это таким образом и включить эту проблему. |
| Закрыть изменение | Это изменение цикл завершена, т.е. ЗАПИСЬ В ЖУРНАЛ ИЗМЕНЕНИЙ завершена. |
Практические результаты
Помимо действий, диаграмма данных процесса (рисунок 1) также показывает Практические результаты каждого действия, то есть данных. Эти результаты или концепции описаны в таблице 3; в этом контексте наиболее важными понятиями являются: ЗАПРОС НА ИЗМЕНЕНИЕ и ИЗМЕНИТЬ ЗАПИСЬ В ЖУРНАЛЕ.
Некоторые концепции определены автором (то есть без ссылки), потому что либо не удалось найти (хороших) определений, либо они являются очевидным результатом какой-либо деятельности. Эти понятия отмечены звездочкой («*»). Свойства концепций были исключены из модели, потому что большинство из них тривиальны, и в противном случае диаграмма могла бы быстро стать слишком сложной. Кроме того, некоторые концепции (например, ЗАПРОС НА ИЗМЕНЕНИЕ, ВЫПУСК СИСТЕМЫ) подходят для управление версиями подход, предложенный Вердом,[6] но это также не учтено из-за ограничений сложности диаграммы.
| Концепция | Описание |
|---|---|
| ТРЕБОВАНИЕ | Требуемая функциональность компонента (или элемента; НАСА, 2005). |
| ОТЧЕТ О ПРОБЛЕМЕ | Документ с описанием проблемы, которую не может решить сотрудник службы поддержки уровня 1; содержит такие элементы, как дата, контактная информация лица, сообщившего о проблеме, причина проблемы, местоположение и описание проблемы, предпринятые действия и решение, но это не показано на диаграмме (Dennis, et al., 2002). |
| ЗАПРОС НА ИЗМЕНЕНИЕ | Документ с описанием запрошенного изменения и его важности; могут возникать из ОТЧЕТОВ О ПРОБЛЕМАХ, усовершенствований системы, других проектов, изменений в базовых системах и высшего руководства, которые здесь обобщены как ТРЕБОВАНИЯ (Dennis, et al., 2002). Важный атрибут: решение «идти / не принимать», т.е. будет ли изменение выполнено или нет? |
| ИЗМЕНИТЬ ЗАПИСЬ В ЖУРНАЛЕ * | Четкая запись в коллекции всех изменений (например, для проекта); состоит из ЗАПРОСА ИЗМЕНЕНИЯ, ИЗМЕНЕНИЯ ТЕХНИЧЕСКОЙ ОСОБЕННОСТИ, ИЗМЕНЕНИЯ ЗАТРАТ И ПРЕИМУЩЕСТВ, АНАЛИЗА ВОЗДЕЙСТВИЯ ИЗМЕНЕНИЯ, ПЛАНИРОВАНИЯ ИЗМЕНЕНИЙ, ОТЧЕТА ОБ ИСПЫТАНИЯХ и ПРОВЕРКИ ИЗМЕНЕНИЙ. Не все они должны быть включены, если процесс завершается раньше (то есть если изменение не реализовано). |
| ИЗМЕНЕНИЕ ТЕХНИЧЕСКОЙ ОСОБЕННОСТИ | Концепция, которая указывает, могут ли «надежные аппаратные и программные средства, технические ресурсы удовлетворить потребности предлагаемой системы [т.е. запрос на изменение] может быть приобретен или разработан организацией в требуемое время »(Vogl, 2004). |
| ИЗМЕНИТЬ РАСХОДЫ И ПРЕИМУЩЕСТВА | Ожидаемые усилия, необходимые для внедрения, и преимущества (например, экономия затрат, увеличение доходов), полученные от внедрения изменения. Также называется экономической осуществимостью (Vogl, 2004). |
| ИЗМЕНИТЬ АНАЛИЗ ВОЗДЕЙСТВИЯ | Оценка степени изменения (Rajlich, 1999). |
| ИЗМЕНИТЬ ПЛАНИРОВАНИЕ | «Схема, метод или дизайн для достижения какой-либо цели или достижения чего-либо [т.е. изменение] »(Джорджтаунский университет, без даты), в данном случае - изменение. |
| ЭЛЕМЕНТ | «Неспецифический термин, используемый для обозначения любых товар, включая системы, подсистемы, сборки, подсистемы, узлы, наборы, аксессуары, компьютерные программы, компьютерное программное обеспечение или части »(Rigby, 2003); имеет (перекрытие) подтипы ДОБАВЛЕННЫЙ ТОВАР и ИЗМЕНЕННЫЙ ТОВАР. |
| ДОБАВЛЕННЫЙ ТОВАР * | Понятно: недавно созданный ЭЛЕМЕНТ; подтип ITEM. |
| ИЗМЕНЕННЫЙ ПУНКТ * | Не требует пояснений: ПУНКТ, который уже существовал, но был изменен; подтип ITEM. |
| ОТЧЕТ ОБ ИСПЫТАНИЯХ | «Документ, описывающий проведение и результаты тестирования системы или компонента [затронутого изменением]» (IEEE, 1991). |
| ДОКУМЕНТАЦИЯ | Согласно определению Библиотеки государственного университета Пенсильвании (2004 г.), ДОКУМЕНТАЦИЯ - это «[напечатанный] материал, который сопровождает другие материалы (обычно не книги), и который объясняет, дает инструкции по использованию или иным образом действует как руководство к основным материалам. . » В этом контексте это также могут быть цифровые материалы или даже обучение, если они относятся к (частям) системы. |
| ВЫПУСК СИСТЕМЫ | «Товары, выпущенные для продажи или публичного показа» (Принстонский университет, 2003 г.). Состоит из одного или нескольких ЭЛЕМЕНТОВ и прилагаемой ДОКУМЕНТАЦИИ. |
| ИЗМЕНИТЬ ВЕРИФИКАЦИЮ | Определение того, соответствует ли результат внедрения изменения требованиям, установленным ранее (Rigby, 2003). |
Помимо просто «изменений», можно также различать отклонения и отказы.[7] Отклонение - это разрешение (или запрос на него) отступить от требования элемента до его создания. По сути, отказ от прав такой же, но во время или после создания элемента. Эти два подхода можно рассматривать как минималистичное управление запросами на изменение (то есть отсутствие реального решения проблемы).
Примеры
Хороший пример процесса управления запросами на изменение в действии можно найти в разработка программного обеспечения. Часто пользователи сообщают об ошибках или хотят получить новые функции в своих программах, что приводит к Запрос на изменение. В программное обеспечение продукта Затем компания изучает техническую и экономическую осуществимость этого изменения и, следовательно, решает, действительно ли это изменение будет реализовано. Если это действительно так, изменение необходимо запланировать, например, путем использования функциональные точки. Фактическое выполнение изменения приводит к созданию и / или изменению программный код и когда это изменение распространяется, оно, вероятно, вызывает изменение и других фрагментов кода. После того, как первоначальные результаты тестирования покажутся удовлетворительными, документацию можно обновить и выпустить вместе с программным обеспечением. Наконец, менеджер проекта проверяет изменение и закрывает эту запись в журнале изменений.
Еще одна типичная область управления запросами на изменение в том виде, в котором она рассматривается здесь, - это производство домен. Возьмем, к примеру, разработку и производство машина. Если, например, будет обнаружено, что подушки безопасности транспортного средства автоматически заполняются воздухом после поездки на большие расстояния, это, без сомнения, приведет к жалобам клиентов (или, надеюсь, сообщениям о проблемах на этапе тестирования). В свою очередь, они создают запрос на изменение (см. Рисунок 2 справа), который, вероятно, оправдывает изменение. Тем не менее, необходимо провести - скорее всего, упрощенный - анализ затрат и выгод, после чего запрос на изменение может быть одобрен. После анализа влияния на дизайн и производственные графики автомобилей можно составить план внедрения изменений. Согласно этому плану, изменение действительно может быть реализовано, после чего новая версия автомобиля, надеюсь, будет тщательно протестирована, прежде чем она будет представлена публике.
На промышленных предприятиях
Поскольку сложные процессы могут быть очень чувствительны даже к небольшим изменениям, правильное управление изменениями на промышленных объектах и процессах признано критически важным для безопасности. В США, OSHA имеет правила, регулирующие порядок внесения и документирования изменений. Основное требование состоит в том, чтобы тщательный анализ предлагаемого изменения проводился мультидисциплинарной командой, чтобы гарантировать использование как можно большего количества возможных точек зрения, чтобы минимизировать шансы пропустить опасность. В этом контексте управление запросами на изменение известно как Управление изменениями или MOC. Это лишь один из многих компонентов Управление производственной безопасностью, раздел 1910.119 (l) .1
Смотрите также
- Изменить управление
- Управление запросами на изменение
- Порядок инженерных изменений, Запрос на изменение
- PRINCE2
- ITIL
- Управление версиями
- Управление релизами
- Жизненный цикл выпуска программного обеспечения
- Управление жизненным циклом приложений
- Системная инженерия
- Система отслеживания проблем
Рекомендации
- ^ Црнкович, Асклунд и Перссон-Дальквист, 2003 г.
- ^ Деннис, Уиксом и Тегарден, 2002 г.
- ^ Хинли 1996.
- ^ Хуанг и Мак, 1999.
- ^ а б Вообще-то нет обе Требуется новая функциональность и проблема Encounter имеют произойти, чтобы получить ЗАПРОС НА ИЗМЕНЕНИЕ; обычно будет только один из двух. Примерно к этому значению приближается их моделирование как неупорядоченные действия; альтернативой может быть создание двух отдельных «начальных точек» (то есть начальных состояний), указывающих на изменение запроса.
- ^ Верд 2006
- ^ Скотт и Нисс, 2001.
дальнейшее чтение
- Црнкович И., Асклунд У. и Перссон-Дальквист А. (2003). Внедрение и интеграция управления данными о продукте и управления конфигурацией программного обеспечения. Лондон: Artech House.
- Деннис, А., Уиксом, Б.Х. И Тегарден, Д. (2002). Системный анализ и дизайн: объектно-ориентированный подход с UML. Хобокен, Нью-Йорк: John Wiley & Sons, Inc.
- Джорджтаунский университет (без даты). Хранилище данных: глоссарий. Получено 13 апреля 2006 г. из: https://web.archive.org/web/20060423164505/http://uis.georgetown.edu/departments/eets/dw/GLOSSARY0816.html.
- Хинли, Д.С. (1996). Управление эволюцией программного обеспечения: процессно-ориентированная перспектива. Информационные и программные технологии, 38, 723-730.
- Хуанг, Г. И Мак, К. (1999). Текущая практика управления инженерными изменениями в обрабатывающей промышленности Великобритании. Международный журнал операций и управления производством, 19(1), 21-37.
- IEEE (1991). Стандартный глоссарий терминологии программной инженерии (ANSI). Институт инженеров по электротехнике и электронике. Получено 13 апреля 2006 г. из: http://www.ee.oulu.fi/research/ouspg/sage/glossary/#reference_6.
- Мякяряйнен, М. (2000). Процессы управления изменениями программного обеспечения при разработке встроенного программного обеспечения. Кандидатская диссертация. Эспоо: VTT Publications. Доступно онлайн: http://www.vtt.fi/inf/pdf/publications/2000/P416.pdf.
- НАСА (2005). Программа NASA IV&V Facility Metrics Data Program - Глоссарий и определения. Получено 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/ каталогизация / ccl / glossary.htm.
- Принстонский университет (2003 г.). WordNet 2.0. Получено 13 апреля 2006 г. из: http://dictionary.reference.com/search?q=release.
- Райлих, В. (1999). Изменение и развитие программного обеспечения. В Pavelka, J., Tel, G. & Bartošek, M. (Eds.), СОФСЕМ'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 [ограниченный доступ].