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