Процесс сопровождения программных средств является одним основных этапов жизненного цикла программных средств. Согласно ГОСТ Р ИСО/МЭК 12207–2010 процесс сопровождения определяет работы персонала сопровождения, то есть организации, которая предоставляет услуги по сопровождению программного продукта, состоящие в контролируемом изменении программного продукта с целью сохранения его исходного состояния и функциональных возможностей [1].
Параллельно процессу сопровождения происходит доработка системы. Зачастую устранением возникших проблем и разработкой новой функциональности занимается одна команда разработчиков. Чаще всего это происходит из-за нехватки человеческих ресурсов. Так как основной задачей команды разработчиков является создание новой функциональности системы, задачи сопровождения (устранение ошибок) часто решаются в последнюю очередь. Таким образом, задачи сопровождения долгое время ожидаю решения, что приводит к срывам сроков закрытия обращения от пользователей системы. Одной из причин такой ситуации может являться отсутствие модели взаимодействия команд и методов приоритезации задач.
Проанализировав процесс сопровождения государственной автоматизированной информационной системы были определены основные проблемы.
Во-первых, отсутствие единого входа задач. Создать задачу и назначить ее на разработчиков может любой из специалистов группы сопровождения. Это приводит к тому, что по одной и той же проблеме может быть создано несколько задач. При этом никем не оценивается необходимость создания задачи.
Во-вторых, нигде не ведется общий список задач, направленных со стороны команды сопровождения команде разработке. В результате специалист не может сразу же определить, существует ли уже задача по конкретной проблеме. Также нельзя оперативно определить объем задач со стороны сопровождения.
В-третьих, отсутствует механизм приоритезации задач. После создания задачи, она назначается на главного специалиста команды разработки. При этом нет никакой оценки срочности задачи. В результате, не срочные задачи могут быть выполнены первыми, в то время как более приоритетные задачи теряются в общем списке задач разработчиков.
Отдельно стоит отметить отсутствие отсутствие единой системы. У каждой из команд имеется своя система. Команда сопровождения работает с Системой управления эксплуатацией Заказчика (далее СУЭ). В данную систему приходят все заявки от пользователя, идет учет имеющихся заявок, отслеживается время ожидания и статусы заявок. Команда разработчиков работает с программой управления разработкой Jira. В ней идет планирование работы на ближайшее время, распределяются задачи между разработчиками, создаются новые задачи.
Анализ инструментальных средств управления ИТ-услугами показал, что на рынке существует достаточно большое количество систем данного класса. Системы сходи по функциональным возможностям, большинство их различий незначительны. Однако, данные системы на рассчитаны на управления задачами и их использование не решит одну из проблем — отсутствие единого инструмента. Более того расстановка приоритетов заявок реализована субъективно, в большинстве случаев имеется три уровня приоритета: высокий, средний и низкий. Для повышения эффективности работы и сокращения времени передачи в разработку необходимо, чтобы приоритет рассчитывался более объективно. Таким образом, целесообразно рассмотреть вариант создания единой системы эксплуатации, которая бы объединяла заявки из системы группы сопровождения СУЭ и задачи команды разработчиков Jira.
Предлагаемая модель взаимодействия состоит из следующих частей:
– модернизированный процесс сопровождения Государственной автоматизированной информационной системы;
– метод приоритезации задач;
– Единую систему эксплуатации.
В рамках изменения процесс добавляется новый этап — оценка приоритета задачи. На данной этапе каждая задача будет оцениваться по ряду критериев. Итоговая оценка будет определять приоритет задачи. В команде сопровождения также добавляется новая роль — Менеджер задач. В обязанности менеджера задач входит:
– централизованный сбор запросов на создание задачи по заявкам от команды сопровождения;
– создание задач и передача их в разработку;
– мониторинг состояния задач по заявки.
Данные изменения позволят решить проблемы отсутствия единого входа задач, отсутствия механизма приоритезации задач и оценку общего объема задач.
Для определения наиболее приоритетных задач был разработан метод, основанный на выставлении экспертных оценок по ряду критерий. В рамках модели были предложены следующие критерии:
– критичность ошибки;
– признак отчетного периода;
– количество обращений по аналогичной проблеме.
Для каждого критерия были выявлены варианты значения и веса. Оценка приоритета считается как сумма произведений веса критерия на его значения.
где Pi — приоритет i-ой задачи, i=1…..n, n — количество задач;
aj — вес j-ого критерия;
kj — оценка по j-ому критерию.
Единая система эксплуатации (далее ЕСЭ) будет получать данные из СУЭ и JIRA путем двухсторонней интеграции данных [2]. Прежде чем разрабатывать структуру системы необходимо понять, как система взаимодействует с внешней средой. Для этого была построена контекстная диаграмма ЕСЭ (Рисунок 1).
Рис. 1. Контекстная диаграмма ЕСЭ
Исходя из общей структуры системы, а также входящих и выходящих данных построим контекстную диаграмму для отображения взаимодействия модулей внутри ЕСЭ (Рисунок 2)
Рис. 2. Модель структуры ЕСЭ
Таким образом в рамках системы были выделены следующие модули.:
Модуль обработки заявок. Один из основных модулей системы. В рамках этого модуля формируется список заявок пользователей, происходит распределение заявок на специалистов и предоставляется решение по заявкам.
Модуль мониторинга задач. Второй основной модуль. Он отвечает за мониторинг созданных на стороне сопровождения задач. В списке задач отображаются только те задачи, которые были созданы на основе заявок.
Модуль аналитической отчетности. Предназначен для мониторинга текущего состояния очереди заявок и координировать работу команды сопровождения. В модуле предполагается наличие как уже готовых шаблонов отчетов, так и создание пользовательских отчетов.
База знаний. Содержит в себе справочную информация по всем модулям системы, а также уже встречающиеся проблемы с их решением. Направлено на сокращений времени обработки каждого из обращения
Хранилище. Хранение архивных заявок.
По итогам апробации предложенной модели были получены следующие результаты:
– время ожидания задачи в очереди сократилось на 50 %;
– время для типовых операция по заявке сократилось на 75 %;
– время для составления отчетности сократилось на 80 %.
Литература:
1 ГОСТ Р ИСО/МЭК 12207–2010. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств
2 Интеграция программного обеспечения. Описание процесса от бизнес консультанта [Электронный ресурс]/Хабрахабр — URL https://habrahabr.ru/company/trinion/blog/245615/ (дата обращения 10.03.2018)
