Данный документ содержит описание процессов, обеспечивающих поддержание жизненного цикла программного обеспечения, в том числе устранение неисправностей, выявленных в ходе эксплуатации программного обеспечения, совершенствование программного обеспечения.
Выпуск продукта осуществляется посредством создания и передачи заказчику релизов и патчей продукта.
Создание новых релизов проходит следующие стадии:
проектирование,
разработка,
тестирование,
передача,
поддержка версий продукта и доработка во время эксплуатации.
В процессе создания новых релизов ПО участвуют команды аналитики, разработки, тестирования и технической поддержки.
1.1 Проектирование
На этапе проектирования формулируются ТЗ к новому релизу программного продукта, составленные на основе:
дорожной карты развития продукта,
обратной связи от заказчика.
В ТЗ определяется список доработок, необходимых для внедрения в данном релизе, определяются трудозатраты и сроки на разработку и внедрение этих доработок.
1.2 Разработка
На этапе разработки происходит создание кодовой базы нового релиза продукта:
создаются новые модули программы, реализующие новый функционал,
вносятся изменения в код предыдущей сборки продукта, согласно ТЗ.
1.3 Тестирование
Тестирование продукта производится командой инженеров-тестировщиков, выявляющие дефекты сборки нового релиза, а также влияние доработок на работоспособность функционала продукта в целом. Проводятся следующие виды тестирования:
Регрессионное тестирование,
Ручное функциональное тестирование.
В результате проведение тестирования выявляются и исправляются дефекты продукта.
1.4 Передача
Передача продукта заказчику состоит из следующих этапов:
1. После подготовки нового релиза, архив с дистрибутивом новой версии продукта выкладывается на страницу Кайман, в раздел, где выложены архивные и актуальная версии. При этом выкладываемый архив помечается как актуальная версия, предыдущая версия становится архивной.
В состав релиза входит:
Непосредственно дистрибутив с новой версией ANTS,
Release notes,
Инструкция по установке.
2. Заказчику по электронной почте высылается уведомление о выходе новой версии продукта.
В письмо обязательно входят:
Указание номера новой версии продукта,
Краткое описание новой функциональности,
Ссылка на страницу с архивом новой версии продукта.
3. Заказчик скачивает актуальный архив с указанной страницы и, пользуясь Инструкцией по установке, производит обновление ANTS.
1.5 Поддержка версий продукта и доработка
Для упорядочивания процесса выпуска продукта в отношении релизов и патчей принят следующий порядок обозначения:
«Название продукта» v«РМАЖ».«РМИН», где РМАЖ – номер мажорной версии релиза РМИН – номер минорной версии релиза
Пример обозначения продукта с учетом номеров версий и патчей: ANTS v1.0
В отношении подхода к выпуску релизов и патчей применяются следующие правила (одно из перечисленных):
Выпуск новой мажорной версии релиза осуществляется в случаях, когда поставляемая в рамках релиза функциональность или используемые технологии существенно изменились с момента предыдущей версии (высокая степень воздействия на функциональность). Для новой мажорной версии релиза ее номер увеличивается на 1 относительно предыдущего.
Выпуск новой минорной версии релиза осуществляется в случаях, когда поставляемая в рамках релиза функциональность или используемые технологии несущественно изменились с момента предыдущей версии (средняя степень воздействия на функциональность). Для новой минорной версии релиза ее номер увеличивается на 1 относительно предыдущего.
В ходе доставки новой версии Заказчикам производитель сопровождает версию, как минимум, двумя документами:
Release notes – документ, содержащий сведения об изменениях и исправлениях в продукте, привносимых версией
Инструкция по установке – руководство, описывающее порядок действий для корректной установки версии.
1.6 Правила по вводу и выводу версий продукта в/из техническую поддержку
Для ввода версии продукта в техническую поддержку и вывода из технической поддержки применяются следующие правила:
Версия продукта, включая релизы и патчи получает техническую поддержку после официального донесения до Заказчиков информации по ее выпуску.
В случае обращения заказчика в техподдержку с проблемой, решенной в версии продукта более поздней, чем установленная у заказчика, производитель имеет право в качестве рекомендации по решению проблемы предложить обновление до соответствующей версии продукта.
Вывод версии продукта из технической поддержки может осуществляться не ранее, чем через 6 месяцев после соответствующего уведомления Заказчикам.
2. Техническая поддержка продукта и устранение сбойных ситуаций
2.1 Список сокращений
2.2 Общее описание
Услуги, оказываемые в рамках технической поддержки, включают в себя:
предоставление доступа в систему регистрации инцидентов, связанных с функционированием ПО;
квалификация и анализ обращений, поступивших в систему регистрации инцидентов;
консультации по вопросам функционирования ПО в соответствии с технической и пользовательской документацией, в случае, если требуемая информация не содержится в технической документации к ПО;
предоставление очередных обновлений ПО, содержащих исправления причин инцидентов, зарегистрированных в системе регистрации инцидентов квалифицированных как «ошибка», а также новую/улучшенную функциональность;
для критических случаев – предоставление внеочередных обновлений ПО содержащих исправления прочих инцидентов, зарегистрированных в системе регистрации инцидентов и квалифицированных как «ошибка»;
Информирование Заказчика о планах поставки очередных обновлений ПО в течение срока действия настоящего Договора.
2.3 Условия исполнения обязательств по сопровождению
В течение срока действия Договора технической поддержки Заказчик имеет право обращаться к Исполнителю за оказанием услуги по сопровождению ПО (далее – Услуга) в соответствии с настоящим Регламентом и положениями Договора.
Запрос, означает документированное обращение Заказчика за Услугой к Исполнителю по каналам, указанным в п. 2.3.1 настоящего Регламента. Обращение считается новым, если обращение не связано с предыдущими обращениями Заказчика, либо относится к уже принятым Заказчиком услугам Исполнителя.
Запросы на поддержку принимаются в том случае, если они поданы лицами, указанными в Договоре на сопровождение, в списке уполномоченных представителей Заказчика.
При изменении списка уполномоченных представителей Заказчика, Заказчик информирует Исполнителя о внесении изменений.
2.4 Порядок оказания услуг
Заказчик при подаче запроса на техническую поддержку придерживается правила – одному запросу соответствует одна проблема, для четкой идентификации проблемы при выполнении. В случае возникновения при выполнении запроса новых вопросов или проблем, по ним открываются новые запросы.
Заказчик при подаче Запроса на поддержку указывает следующие сведения:
наименование системы, требующей поддержки;
описание проблемы;
предполагаемый приоритет проблемы (описание приоритетов представлено в п.п. 2.6).
Каждому Запросу присваивается уникальный регистрационный номер в системе регистрации инцидентов и сообщается. Сервисный центр Исполнителя сообщает Заказчику номер, присвоенный Запросу при регистрации.
Зарегистрированный Запрос обрабатывается и выполняется согласно установленной системе приоритетов. Действия специалистов Исполнителя по выполнению запроса документируются в системе регистрации инцидентов.
Заказчик обязуется выполнять все рекомендации и предоставлять необходимую дополнительную информацию специалистам Исполнителя для своевременного решения Запроса. Запрошенная дополнительная информация, рекомендации и ответы Заказчика документируются Исполнителем в системе регистрации инцидентов. Если ответ Исполнителя на Запрос Заказчика зависит от третьей стороны (например, в виде информации, лицензий, консультации и т. д.), то Исполнитель обязуется поставить Заказчика в известность.
Доставка Ответа осуществляется либо через ответный email, либо через телефон, в случае создания Запроса по телефону.
Завершенный запрос. После доставки Ответа запрос считается Завершенным, и находится в таком состоянии до получения подтверждения от Заказчика о решении инцидента, выполнении иных работ. В случае аргументированного несогласия Заказчика с завершением запроса, выполнение запроса продолжается. Закрытие Запроса.
Завершенный запрос переходит в состояние закрытого после получения Исполнителем подтверждения от Заказчика о решении запроса. Закрытие запроса подтверждает представитель Заказчика, зафиксированный в списке ответственных лиц, В случае отсутствия ответа Заказчика о завершении запроса в течение 7 (Семи) рабочих дней, запрос считается закрытым, Закрытие Запроса может инициировать Заказчик, если надобность в ответе на запрос пропала.
2.5 Отчет о состоянии обращений
Исполнитель хранит список всех текущих и уже закрытых обращений Заказчика. Список содержит следующую информацию:
Общее количество обращений Заказчика. По каждому обращению:
Идентификатор обращения;
Заголовок;
Категория обращения;
Дата получения обращения от Заказчика;
На чьей стороне сейчас обращение (у Исполнителя/Заказчика);
Имя заявителя обращения;
Статус обращения;
Дата предоставления решения Заказчику (если есть);
Количество человеко-часов, затраченное исполнителем на выполнение запроса по сопровождению ПО.
Исполнитель обязуется предоставлять данный список Заказчику по его запросу.
2.6 Описание приоритетов обращений
Запросу должен быть присвоен приоритет, который определяет время обработки данного запроса. Приоритет определяется сотрудником технической поддержки на основе описанной в запросе проблемы.
Приоритет обращения
Период получения первого ответа
Критический. такой приоритет присваивается запросам, где описана проблема, блокирующая работу всего программного продукта у заказчика (полная потеря данных; полная недоступность данных; глобальная неисправность системы, повлекшая её остановку)
2 рабочих часа (в случае обращения после 18:00, ответ по инциденту будет в 11:00 следующего рабочего дня)
Высокий. такой приоритет присваивается запросам, где описана проблема, блокирующая значительную часть функционала программного продукта заказчика (частичная недоступность данных; недоступность либо некорректная отработка внутренней функциональности системы)
4 рабочих часа (в случае обращения после 18:00, ответ по инциденту будет в 13:00 следующего рабочего дня)
Средний. такой приоритет присваивается запросам, где описана проблема, не блокирующая основной функционал программного продукта, однако делающая недоступным часть вторичного функционала (система работоспособна, но уменьшена второстепенная функциональность, отказоустойчивость внутренних/внешних компонентов)
8 рабочих часов
Низкий. такой приоритет присваивается запросам, где описана проблема, не блокирующая функционал продукта или где производится запрос дополнительной информации по системе