1. Целью процесса «Управление Инцидентами» ( Incident Management - IM ) является скорейшее восстановление нормального функционирования ПО и уровня сервиса, определенного в SLA, с минимальными возможными потерями для Заказчика и его Пользователей.
2. Процесс управления инцидентами состоит из следующих шагов:
1. Прием и регистрация инцидентов:
заполнение формы в системе самим Пользователем;
письмо по электронной почте;
по телефону, факсу, ICQ, Skype и т.д. Примем и сортировку поступивших инцидентов осуществляет Диспетчер. Результат: зафиксированный в системе Инцидент, назначенный Консультант по инциденту.
2. Первичная идентификация и классификация инцидентов, начальная поддержка На данном этапе Консультант выполняет
локализацию инцидента: повторение ошибки на тестовом примере, сопоставление и связка с другими инцидентами
тип инцидента: консультация, задание, ошибка, доработка
классификацию инцидента: приоритет, срочность выполнения и пр. Результат:
если Консультанту известно готовое решение по инциденту, он консультирует Пользователя и переходит к закрытию инцидента;
если Консультанту известен способ продолжить работу Пользователя до устранения сбоя, он консультирует Пользователя и передает инцидент в разработку;
если инцидент определен как ошибка или задание (не требует анализа), Консультант передает его в разработку;
если инцидент определен как доработка, Консультант передает его на на анализ
3. Анализ инцидента: На данном этапе Аналитик осуществляет анализ возможности и необходимости функциональной доработки ПО, в случае необходимости пишет постановку на доработку. Результат:
постановка на доработку, и передача в разработку инцидента;
в случае если Аналитику известен способ решения проблемы Пользователя без доработки, сообщает Консультанту, а тот, в свою очередь Пользователю и переходит к закрытию инцидента.
4. Разработка: на данном этапе Ответственный разработчик определяет ответственных за разработку инцидента (либо ошибки и задания автоматически попадают разработчикам по закрепленным за ними разделам), определяет возможность доработки новой функциональности в короткие сроки или передает инцидент в базу перспективных доработок. Разработчик выполняет доработку, устранение ошибки, выполняет сборку проекта и передает на тестирование, вносит запись в систему управления изменениями. Результат:
исправленная ошибка, выполненная доработка;
запись в системе управления изменениями;
пополненная база задач на перспективную разработку.
5. Тестирование: на данном этапе тестировщик проверяет на тестовом ПО работоспособность доработок, в случае обнаружения ошибок возвращает на доработку, в случае успеха включает в новый билд и (если велика срочность исполнения инцидента) передает в службу сопровождения для рассылки изменений и закрытия.
6. Закрытие инцидента: на данном этапе Консультант готовит ответ с решением по инциденту, а также, в случае, если были внесении изменения в ПО, готовит рассылку с изменениями.
-
Опубликовано 12 лет назад #
-
Спроектированный процесс разработки и сопровождения ПО_V1
Файлы
-
ticket_system.png (62.8 KB, 12 downloads) 12 лет old
Опубликовано 12 лет назад # -
-
Версия 2
Файлы
-
ticket_system.bpm (38.5 KB, 10 downloads) 12 лет old - ticket_systemv2.png (139.2 KB, 23 downloads) 12 лет old
Опубликовано 12 лет назад # -
-
Добавили реакцию пользователя
Файлы
- ticket_systemv2.5.png (159.3 KB, 29 downloads) 12 лет old
- ticket_system.v2.5.bpm (40.5 KB, 10 downloads) 12 лет old
Опубликовано 12 лет назад # -
-
Цитирую alexsteptlt:
6. Закрытие инцидента: на данном этапе Консультант готовит ответ с решением по инциденту, а также, в случае, если были внесении изменения в ПО, готовит рассылку с изменениями.После отправки уведомления клиенту о решении инцидента, консультант должен дождаться "угу" от Пользователя. Если в течении 5 дней "угу" не приходит, то инцидент автоматически закрывается, если приходит "не угу" то, инцидент повторно проходит все стадии (кроме самой регистрации).
Опубликовано 12 лет назад # -
Версия 3 подоспела
Файлы
- ticket_system_devel.png (27.1 KB, 19 downloads) 12 лет old
- ticket_system_process_ticket.png (32 KB, 15 downloads) 12 лет old
- ticket_system.png (182 KB, 64 downloads) 12 лет old
- ticket_system_v3.bpm (45 KB, 39 downloads) 12 лет old
Опубликовано 12 лет назад # -
-
Если окажется, что связанная задача будет решена до выполнения активности "прикрепить к существующему инциденту", то процесс зависнет. Поэтому лучше использовать гейт на проверку наличия (или отсутствия) решения по связанной задаче.
А еще бы я разделил нормальное завершение (когда инцидент не анализируется) и завершение через прикрепленное событие-ошибку "анализировать инцидент". Только в этом случае возможно будет разделить инциденты, которые решались "готовым ответом" от инцидентов, которые требовали анализа.
Файлы
- Image_004.jpg (22.3 KB, 5 downloads) 12 лет old
Опубликовано 12 лет назад # -
-
С первым замечанием согласен.
"Анализировать инцидент" - это название подпроцесса, а не событие. Событие не подписано (это упущение), очевидно имеется в виду бизнес-исключение "инцидент является дубликатом".
Но в любом случае согласен, лучше показать два разных завершения.
Опубликовано 12 лет назад # -
А стандартные "молотки" чем не угодили? Инструментов под эту задачу, по-моему, немеряно всяких, толстых-тонких, платных-бесплатных. Или это просто потренироваться и попутно тридумать лисапед?
Опубликовано 12 лет назад # -
Эти процессы выбирают для практики представители крупных софтверных компаний. Можете не сомневаться - что есть и чего нет в готовых инструментах они знают отлично.
Опубликовано 12 лет назад # -
Леонид,
1. Подпроцесс "Обработка инцидента" - не совсем понятно, что там делается помимо проверки на существующий инцидент (предположим, что развели все-таки выходы - присоединить к существующему или это новый инцидент). А на выходе из этого подпроцесса стоит развилка "Способ решения". Значит подпроцесс "Обработка инцидента" должен давать ответ "Отказ", "Консультация" или "Разработка". Где это делается-то? Получается, что в подпроцессе Вы решаете один вопрос, а на выходе проверяете совсем другое?
2. Оценка возможности доработки делается в процессе "Исполнение доработки", а отказ в доработке вы делаете раньше этой оценки. Абсолютно нелогично. Либо отказали, даже не оценив, либо проделали какую-то кучу действий, передали в разработку, а потом оценили, что доработка невозможна.
3. Подпроцесс "Передача в разработку" возращает два варианта завершения: работа выполнена или не выполнена. Дальше вы шлете ответ заказчику в обоих случаях и ожидаете от него ответа? Т.е. если работа не выполнена, Вы ждете ответа "Решение помогло?" Это цинично :) А если они так же цинично ответят в случае отказа, что решение не помогло, то вы готовы повторить этот сценарий еще раз? (Типа, опять трясти надо? :) )
4. У Вас в процессе планирования есть задание "Решить о возможности доработки", после которой нет никакой проверки. Зачем решать о возможности, если решение заведомо положительное? Вероятно, имеется в виду планирование ресурсов и сроков? Тогда этот шаг надо объединить со следующим и не плодить заданий.Опубликовано 12 лет назад #
Ответ
Вы должны авторизоваться, чтобы публиковать сообщения.