Настоящий документ представляет собой подробное описание процессов, поддерживающих жизненный цикл программного обеспечения. Он включает в себя процедуры по выявлению и устранению неисправностей, возникших в процессе эксплуатации, а также мероприятия по постоянному совершенствованию и обновлению программного обеспечения.
Выпуск продукта осуществляется через разработку и передачу заказчику релизов и патчей.
Процесс создания новых релизов включает следующие этапы:
В создании новых релизов программного обеспечения участвуют команды аналитиков, разработчиков, тестировщиков и специалистов по технической поддержке.
На этапе проектирования разрабатываются технические задания (ТЗ) для нового релиза программного продукта. ТЗ формируется на основе следующих факторов:
Дорожная карта представляет собой стратегический документ, в котором изложены долгосрочные цели и планируемые улучшения продукта. Команда аналитиков и проектных менеджеров изучает дорожную карту, чтобы выделить приоритетные задачи и нововведения, которые должны быть реализованы в новом релизе.
Обратная связь собрана через различные каналы, включая службы поддержки, аккаунт-менеджеров и прямые отзывы пользователей. Эта информация анализируется для выявления ключевых потребностей и предложений пользователей и клиентов, которые могут улучшить качество и функциональность продукта.
В процессе составления ТЗ выполняются следующие шаги:
На основе анализа дорожной карты и обратной связи от заказчиков, команда формирует список конкретных доработок и улучшений. Эти доработки включают исправления ошибок, добавление новых функций и улучшение существующей функциональности.
Для каждой доработки оцениваются необходимые ресурсы и время на её реализацию. Это включает трудозатраты на проектирование, разработку, тестирование и внедрение изменений.
Разрабатывается план-график, включающий временные рамки и конкретные сроки для выполнения каждой задачи. Сроки определяются с учетом приоритетов, сложности задач и доступных ресурсов.
В итоге, сформированное ТЗ представляет собой подробный план по реализации нового релиза программного продукта. Документ согласовывается со всеми заинтересованными сторонами и утверждается для дальнейшей работы, обеспечивая структурированное и целенаправленное выполнение проекта.
На этапе разработки происходит создание кодовой базы нового релиза программного продукта. Этот этап включает следующие основные шаги:
На основе утвержденного технического задания (ТЗ) разработчики реализуют новые функциональные модули, которые добавляют или расширяют возможности продукта. Каждый новый модуль создается с учетом лучших практик программирования, что включает написание чистого, эффективного и поддерживаемого кода. Модули проектируются таким образом, чтобы они были легко интегрируемы с существующей архитектурой программного обеспечения.
В дополнение к созданию новых модулей, разработчики вносят изменения в существующий код продукта. Это включает обновление и оптимизацию текущих компонентов системы в соответствии с требованиями, указанными в ТЗ. Каждое изменение тщательно документируется, чтобы обеспечить прозрачность и возможность отслеживания изменений.
В процессе разработки используются различные методологии, такие как Agile (Scrum), чтобы обеспечить гибкость и оперативность выполнения задач.
Основные аспекты разработки включают:
Каждая часть кода сопровождается документированием, что облегчает его дальнейшее сопровождение и поддержку. Это включает комментарии в коде, а также внешнюю техническую документацию.
Важным этапом является проведение код-ревью, где созданный код проверяется другими членами команды для выявления потенциальных ошибок и улучшения качества кода. Контроль качества также включает автоматическое тестирование, использование статического анализа и других инструментов для уменьшения количества ошибок.
Новый код и обновленные модули интегрируются в основной проект, после чего производится сборка проекта для дальнейшего тестирования. Это часто осуществляется с помощью систем непрерывной интеграции (CI), что позволяет оперативно выявлять и исправлять проблемы, возникающие при интеграции кода.
Таким образом, этап разработки направлен на создание качественной и функциональной кодовой базы, обеспечивающей выполнение всех требований нового релиза программного продукта, указанных в ТЗ.
Тестирование нового релиза продукта выполняется командой инженеров-тестировщиков, которые выявляют дефекты сборки и оценивают влияние внесенных доработок на общую работоспособность функционала продукта. Этот этап включает следующие виды тестирования:
Регрессионное тестирование проводится для проверки, что изменения в коде (новые функции или исправления) не нарушили существующую функциональность продукта. Тестировщики запускают набор заранее подготовленных тестов, чтобы убедиться, что основные функции продукта продолжают работать корректно после внедрения новых изменений. Регрессионное тестирование помогает минимизировать риск возникновения новых ошибок в ранее стабильных частях системы.
Ручное функциональное тестирование заключается в проверке новых функций и модулей в соответствии с техническим заданием (ТЗ). Тестировщики вручную проходят по сценариям использования, чтобы убедиться, что новые функции работают корректно и соответствуют требованиям, описанным в ТЗ. Это также включает тестирование пользовательского интерфейса, проверки на совместимость и корректное выполнение всех бизнес-процессов.
Процесс тестирования также включает следующие аспекты:
При выявлении дефектов тестировщики создают подробные отчёты о найденных проблемах, включая описание ошибки, шаги для ее воспроизведения, ожидаемое и фактическое поведение системы. Это помогает разработчикам оперативно исправлять проблемы.
Обнаруженные дефекты передаются команде разработчиков для исправления. После внесения корректировок разработчиками, тестировщики повторно проверяют исправленные области, чтобы убедиться в устранении ошибок и отсутствии новых проблем.
В дополнение к ручным тестам, наша команда используют автоматизированное тестирование для повышения эффективности. Сценарии автотестов запускаются автоматически и позволяют быстро провести объемное тестирование.
В результате проведения тестирования устраняются выявленные дефекты, что способствует улучшению стабильности и качества программного продукта перед его релизом. Этот этап играет ключевую роль в обеспечении высокого качества и надежности программного обеспечения, готового для использования клиентами.
Передача продукта заказчику состоит из следующих этапов:
После завершения подготовки нового релиза, архив с дистрибутивом (Docker-образом) выкладывается на страницу GitLab с образами в Yandex Registry. Релиз помещается в раздел, содержащий образы и актуальные версии продукта. Новый образ помечается как актуальная версия, а предыдущая версия становится архивной.
В состав релиза входят:
2. Уведомление заказчика:
Заказчику направляется уведомление о выходе новой версии продукта.
Сообщение содержит:
- Указание номера новой версии продукта,
- Краткое описание новой функциональности,
- Ссылку на страницу с новой версией продукта.
3. Процесс обновления:
Заказчик загружает актуальную версию с указанной страницы в GitLab и, следуя инструкции по установке, производит обновление продукта на новую версию. Инструкция описывает все необходимые шаги для корректного обновления дистрибутива.
Таким образом, заказчик получает доступ к актуальной версии программного продукта и может самостоятельно выполнить обновление с помощью представленных инструкций.
Для упорядочивания процесса выпуска продукта, в отношении релизов и патчей, принят следующий порядок обозначения:
«Название продукта» v«М.В», где
М – номер основной версии релиза (major version)
В – номер второстепенной версии релиза (minor version)
Пример обозначения продукта с учетом номеров версий и патчей: Smart Insider v1.0
В отношении подхода к выпуску релизов и патчей применяются следующие правила:
Новая основная версия релиза выпускается в случаях, когда функциональность или используемые технологии существенно изменены по сравнению с предыдущей версией (имеют высокое влияние на функциональность). Номер мажорной версии увеличивается на 1 относительно предыдущего. Например, с версии 1.0 на версию 2.0.
Новая второстепенная версия релиза выпускается в случаях, когда функциональность или используемые технологии изменены несущественно (среднее влияние на функциональность). Номер минорной версии увеличивается на 1 относительно предыдущей. Например, с версии 1.0 на версию 1.1.
Для выпуска новой версии продукта производитель сопровождает её следующими документами:
Это документ, содержащий подробные сведения об изменениях и исправлениях, внесённых в новую версию продукта. Release notes включают описание новых функций, улучшений, исправленных ошибок и других значительных изменений.
Это руководство, описывающее порядок действий, необходимых для корректной установки и обновления продукта до новой версии. Инструкция включает пошаговое описание процесса установки, требования к системе и рекомендации для предотвращения возможных проблем.
Для ввода версии продукта в техническую поддержку и прекращения ее поддержки применяются следующие правила:
Новая версия продукта, включая релизы и патчи, начинает получать техническую поддержку со момента официального уведомления заказчика о ее выпуске. Это уведомление содержит всю необходимую информацию о новой версии и ее доступности для обновления.
В случае обращения заказчика в техническую поддержку с проблемой, которая была решена в более поздней версии продукта (по сравнению с установленной у заказчика), производитель имеет право рекомендовать обновление до соответствующей новой версии как решение проблемы. Это помогает обеспечить устранение ошибок и улучшение функциональности, уже реализованные в последующих версиях продукта.
Прекращение технической поддержки какой-либо версии продукта может осуществляться не ранее, чем через 6 месяцев с момента соответствующего уведомления заказчиков. За этот период заказчики имеют возможность запланировать и осуществить обновление до более актуальной версии продукта.
Таким образом, данные правила обеспечивают своевременное и прозрачное управление поддержкой различных версий продукта, способствуя оптимальному обслуживанию и удовлетворению потребностей заказчиков.
Услуги, предоставляемые в рамках технической поддержки, включают следующие компоненты:
Обеспечение заказчика доступом к системе регистрации инцидентов, связанных с функционированием программного обеспечения. Это позволяет заказчику самостоятельно фиксировать и отслеживать статус своих обращений.
Проведение квалификации и анализа всех обращений, поступивших в систему регистрации инцидентов. Это включает проверку каждого запроса, определение природы проблемы и установление её причин.
Предоставление консультаций по вопросам функционирования программного обеспечения в соответствии с технической и пользовательской документацией. В случае отсутствия необходимой информации в документации, специалисты технической поддержки оказывают помощь и дают разъяснения.
Предоставление заказчику очередных обновлений программного обеспечения. Эти обновления включают исправления зарегистрированных инцидентов, классифицированных как ошибки, а также новую или улучшенную функциональность продукта.
В критических ситуациях, требующих незамедлительного решения, предоставляются внеочередные обновления программного обеспечения. Эти обновления предназначены для исправления серьёзных инцидентов, зарегистрированных в системе как ошибки, и обеспечивают оперативное устранение проблем.
Регулярное информирование заказчика о планах по выпуску очередных обновлений программного обеспечения в течение срока действия договора на техническую поддержку. Это позволяет заказчику быть в курсе предстоящих изменений и планировать свои действия соответственно.
Этот перечень услуг направлен на обеспечение непрерывной поддержки и улучшение качества обслуживания клиентов, обеспечивая эффективное функционирование и развитие программного обеспечения.
В течение срока действия технической поддержки Заказчик имеет право обращаться к Исполнителю за оказанием услуг по сопровождению программного обеспечения (далее – Услуга) в соответствии с настоящим Регламентом.
Запрос – это документированное обращение Заказчика за Услугой к Исполнителю по предусмотренным каналам связи. Обращение считается новым, если оно не связано с предыдущими обращениями Заказчика или не касается уже принятых услуг.
Запросы на поддержку принимаются, если они поданы лицами, указанными в списке уполномоченных представителей Заказчика.
В случае изменения списка уполномоченных представителей Заказчик должен уведомить Исполнителя о внесении изменений.
Заказчик при подаче запроса на техническую поддержку должен придерживаться правила "одному запросу — одна проблема" для четкой идентификации и выполнения запроса. Если в процессе выполнения запроса возникают новые вопросы или проблемы, по ним открываются новые запросы.
При подаче запроса на поддержку Заказчик указывает следующие сведения:
Каждому запросу присваивается уникальный регистрационный номер в системе регистрации инцидентов. Исполнитель сообщает Заказчику этот номер для отслеживания.
Запросы обрабатываются и выполняются в соответствии с установленной системой приоритетов. Действия специалистов по выполнению запроса фиксируются в системе регистрации инцидентов.
Заказчик обязуется следовать рекомендациям и предоставлять необходимую дополнительную информацию для своевременного решения запроса. Вся дополнительная информация и рекомендации документируются в системе регистрации инцидентов. Если ответ на запрос зависит от третьей стороны (например, информация, лицензии, консультации), Исполнитель уведомляет об этом Заказчика.
Ответ на запрос доставляется через электронную почту или телефон, в зависимости от канала подачи запроса.
Запрос считается завершенным после доставки ответа и получения подтверждения от Заказчика о решении проблемы. В случае несогласия Заказчика с закрытием запроса его выполнение продолжается.
Запрос переходит в состояние закрытого после подтверждения Заказчиком решения проблемы. Если в течение 7 рабочих дней Заказчик не ответит, запрос считается закрытым автоматически. Заказчик может инициировать закрытие запроса, если необходимость в ответе отпала.
Исполнитель ведет учет всех текущих и уже закрытых обращений Заказчика. Этот список содержит следующую информацию:
Исполнитель обязуется предоставлять данный список Заказчику по его запросу.
Запросу присваивается приоритет, который определяет время его обработки. Приоритет устанавливается сотрудником технической поддержки на основе описанной в запросе проблемы.
Этот подход позволяет обеспечить своевременное и приоритетное реагирование на запросы различной критичности, улучшая качество и скорость ответов на обращения заказчиков.