# Описание процессов, обеспечивающих поддержание жизненного цикла программного обеспечения

Документ подготовлен в соответствии с подпунктом «е» пункта 11 Правил формирования и ведения единого реестра российских программ для электронных вычислительных машин и баз данных, утверждённых постановлением Правительства Российской Федерации от 16.11.2015 № 1236.

Документ описывает процессы, обеспечивающие поддержание жизненного цикла программного обеспечения «Rechi Android», в том числе устранение неисправностей, выявленных в ходе эксплуатации, совершенствование программного обеспечения, а также содержит сведения о персонале, необходимом для обеспечения такой поддержки.

**Наименование программного обеспечения:** «Rechi Android»

**Версия:** 0.3.3

**Правообладатель:** ________________________________

**Дата:** ___ __________ 2026 г.

---

## 1. Общие положения

### 1.1. Нормативная основа

Процессы жизненного цикла программного обеспечения организованы с учётом положений ГОСТ Р ИСО/МЭК 12207 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств» и ГОСТ Р ИСО/МЭК 14764 «Информационная технология. Сопровождение программных средств».

### 1.2. Субъект поддержки

Гарантийное обслуживание, техническая поддержка, сопровождение и модернизация программного обеспечения, в том числе модификация его исходного текста, осуществляются правообладателем — ________________________________ — самостоятельно, без привлечения иностранных юридических и физических лиц, а также контролируемых ими организаций.

Все работы по сопровождению выполняются на территории Российской Федерации силами персонала, состоящего в трудовых или гражданско-правовых отношениях с правообладателем.

### 1.3. Стадии жизненного цикла

| Стадия | Содержание |
|---|---|
| Анализ требований | Сбор и приоритизация требований пользователей и рынка, формирование перечня задач |
| Проектирование | Проработка архитектурных решений, фиксация в документах архитектурных решений |
| Реализация | Разработка исходного текста, ревью изменений, модульное тестирование |
| Тестирование | Автоматизированное и ручное тестирование, приёмочный прогон на устройствах |
| Выпуск | Сборка, подписание, публикация дистрибутива |
| Эксплуатация и сопровождение | Приём и обработка обращений, устранение дефектов, выпуск обновлений |
| Снятие с поддержки | Уведомление пользователей, обеспечение выгрузки данных |

---

## 2. Процесс устранения неисправностей

### 2.1. Каналы приёма обращений

| Канал | Реквизиты | Режим |
|---|---|---|
| Электронная почта | dev@v0system.ru | Круглосуточно, обработка в рабочее время |
| Форма обратной связи на сайте | https://v0system.ru/support | Круглосуточно, обработка в рабочее время |
| Телефон | +7 (___) ___-__-__ | с 10:00 до 19:00 по московскому времени в рабочие дни |
| Отзывы в магазине приложений RuStore | Карточка приложения | Обработка в рабочее время |
| Автоматические отчёты об аварийном завершении | Встроенная подсистема мониторинга | Непрерывно |

Рабочее время службы поддержки: с 10:00 до 19:00 по московскому времени в рабочие дни, за исключением нерабочих праздничных дней, установленных законодательством Российской Федерации.

### 2.2. Порядок обработки обращения

1. Регистрация. Обращение регистрируется в системе учёта обращений с присвоением уникального номера. Заявителю направляется подтверждение регистрации с номером обращения.
2. Классификация. Обращение классифицируется по типу (дефект, консультация, предложение по развитию) и по уровню критичности согласно пункту 2.3.
3. Диагностика. Специалист поддержки запрашивает при необходимости дополнительные сведения: версию программного обеспечения, модель устройства, версию операционной системы, диагностический отчёт, сформированный средствами приложения. Аудиозаписи и тексты расшифровок пользователя не запрашиваются и не передаются.
4. Воспроизведение. Дефект воспроизводится на устройстве из парка тестовых устройств правообладателя.
5. Устранение. Подтверждённый дефект регистрируется в системе управления задачами разработки, назначается ответственный исполнитель и целевая версия.
6. Верификация. Исправление проверяется автором обращения либо специалистом службы поддержки на воспроизводящем сценарии.
7. Выпуск. Исправление включается в очередной или внеочередной выпуск в соответствии с уровнем критичности.
8. Закрытие. Заявитель уведомляется об устранении и о версии, в которой оно доступно.

### 2.3. Классификация дефектов и целевые сроки

| Уровень | Определение | Реакция | Устранение |
|---|---|---|---|
| Критический | Потеря или повреждение пользовательских данных; невозможность запуска приложения; нарушение конфиденциальности данных | 4 рабочих часа | 3 рабочих дня, внеочередной выпуск |
| Высокий | Неработоспособность ключевой функции (запись, обработка, экспорт) без обходного пути | 8 рабочих часов | 10 рабочих дней |
| Средний | Неработоспособность функции при наличии обходного пути; существенное снижение производительности | 2 рабочих дня | Очередной плановый выпуск |
| Низкий | Дефекты оформления, неточности текстов, частные замечания | 5 рабочих дней | По мере планирования |

Указанные сроки применяются к обращениям, поступившим по каналам пункта 2.1, и исчисляются с момента регистрации обращения.

### 2.4. Внеочередной выпуск

При выявлении критического дефекта либо уязвимости формируется внеочередной выпуск, содержащий только целевое исправление. Такой выпуск проходит сокращённый цикл тестирования, ограниченный регрессионной проверкой затронутой функциональности и проверкой основных сценариев.

### 2.5. Управление уязвимостями

- Состав используемых сторонних компонентов с открытым исходным кодом фиксируется и пересматривается не реже одного раза в квартал.
- Отслеживаются сведения об уязвимостях по банку данных угроз безопасности информации ФСТЭК России и по публикациям сопровождающих сторонних компонентов.
- Уязвимости, эксплуатируемые в контексте программного обеспечения, устраняются в порядке, установленном для критических дефектов.
- Программное обеспечение не содержит серверной части, обрабатывающей пользовательские данные, что исключает класс уязвимостей, связанных с удалённой компрометацией пользовательских данных.

---

## 3. Процесс совершенствования программного обеспечения

### 3.1. Источники требований

- обращения и предложения пользователей, поступающие по каналам поддержки;
- отзывы и оценки в магазине приложений;
- результаты собственного анализа рынка и технологий распознавания речи;
- изменения требований платформы Android (повышение уровня целевого API, изменения политик работы с микрофоном, фоновыми службами и хранилищем);
- изменения законодательства Российской Федерации, в том числе в области обработки персональных данных;
- результаты внутреннего тестирования и измерений производительности.

### 3.2. Планирование выпусков

Развитие ведётся итерациями. По итогам каждой итерации формируется выпуск-кандидат. Плановые выпуски публикуются не реже одного раза в квартал; внеочередные — по мере необходимости.

Применяется семантическое версионирование вида МАЖОРНАЯ.МИНОРНАЯ.ПАТЧ:

- МАЖОРНАЯ — изменения, нарушающие обратную совместимость форматов данных или сценариев работы;
- МИНОРНАЯ — новая функциональность с сохранением обратной совместимости;
- ПАТЧ — устранение дефектов без изменения функциональности.

Каждому выпуску соответствует монотонно возрастающий код версии, требуемый платформой Android.

### 3.3. Порядок внесения изменений

1. Требование или дефект регистрируется в системе управления задачами.
2. Изменение исходного текста выполняется в отдельной ветви системы контроля версий.
3. Изменение проходит обязательное ревью кода вторым разработчиком.
4. Выполняются автоматические проверки: статический анализ, модульные тесты, сборка.
5. Изменение включается в основную ветвь только после успешного прохождения всех проверок.
6. Перед выпуском выполняется приёмочный прогон по чеклисту на парке физических устройств, включающий сценарии записи, прерываний, обработки длительных записей, теплового и мемори-давления, а также сценарии сохранности данных.
7. Выпуск собирается, подписывается ключом правообладателя и публикуется.

### 3.4. Совместимость и миграция данных

При изменении форматов хранения данных обеспечивается автоматическая миграция данных пользователя при первом запуске новой версии. Откат на предыдущую версию с сохранением данных не гарантируется, о чём пользователь уведомляется в описании выпуска.

### 3.5. Документирование

При каждом выпуске актуализируются:

- описание функциональных характеристик и информация по установке и эксплуатации;
- перечень изменений выпуска, публикуемый на сайте правообладателя и в карточке магазина приложений;
- настоящий документ — при изменении процессов поддержки.

---

## 4. Персонал, необходимый для обеспечения поддержки

### 4.1. Состав ролей

| Роль | Численность | Квалификационные требования | Функции |
|---|---|---|---|
| Руководитель продукта | 1 | Высшее образование; опыт управления программными продуктами от 3 лет | Приоритизация требований, планирование выпусков, взаимодействие с пользователями и партнёрами |
| Разработчик мобильных приложений (Android) | не менее 1 | Высшее техническое образование; владение языком Kotlin, Android SDK, Jetpack Compose; опыт от 3 лет | Разработка и модификация исходного текста, ревью изменений, устранение дефектов |
| Инженер по машинному обучению и обработке речи | не менее 1 | Высшее техническое образование; опыт работы с моделями распознавания речи и средой исполнения ONNX; опыт от 2 лет | Подбор, конвертация и валидация акустических моделей, оптимизация конвейера обработки, контроль качества распознавания |
| Инженер по тестированию | не менее 1 | Высшее или среднее профессиональное техническое образование; опыт тестирования мобильных приложений от 2 лет | Разработка и выполнение тест-планов, приёмочные прогоны на устройствах, регрессионное тестирование |
| Специалист технической поддержки | не менее 1 | Среднее профессиональное или высшее образование; знание платформы Android на уровне пользователя-эксперта | Приём, классификация и обработка обращений, консультирование пользователей, первичная диагностика |

Совмещение ролей одним работником допускается при условии соответствия квалификационным требованиям по каждой совмещаемой роли.

### 4.2. Требования к квалификации в части предметной области

Персонал, участвующий в сопровождении, должен владеть:

- языком программирования Kotlin и платформой Android (уровни API 28–36);
- библиотекой построения интерфейсов Jetpack Compose и принципами реактивного управления состоянием;
- механизмами асинхронного выполнения Kotlin Coroutines;
- принципами работы служб переднего плана, системного планировщика фоновых задач и подсистемы записи звука Android;
- основами цифровой обработки сигналов в объёме, достаточном для работы с частотой дискретизации, передискретизацией и оконными функциями;
- принципами работы моделей автоматического распознавания речи, детектирования речевой активности и диаризации говорящих, средой исполнения ONNX Runtime;
- средствами криптографической защиты платформы Android (Android Keystore, AES-GCM);
- системой контроля версий Git и практиками непрерывной интеграции.

### 4.3. Поддержание квалификации

Обучение персонала осуществляется на рабочем месте, а также посредством участия в профессиональных конференциях и изучения технической документации платформы. При выходе новых версий Android персонал знакомится с изменениями платформы до повышения уровня целевого API.

### 4.4. Территориальная принадлежность персонала

Весь персонал, обеспечивающий поддержание жизненного цикла программного обеспечения, находится на территории Российской Федерации. Привлечение иностранных юридических и физических лиц, а также контролируемых ими организаций к разработке, модификации, адаптации и сопровождению программного обеспечения не осуществляется.

---

## 5. Инфраструктура поддержания жизненного цикла

| Назначение | Средство | Размещение |
|---|---|---|
| Хранение исходного текста | GitFlic | Российская Федерация |
| Управление задачами и обращениями | ________________________________ | Российская Федерация |
| Сборка дистрибутивов | рабочие станции разработчиков и выделенный сборочный сервер правообладателя | Российская Федерация |
| Хранение дистрибутивов и артефактов сборки | ________________________________ | Российская Федерация |
| Распространение | RuStore, сайт правообладателя | Российская Федерация |
| Мониторинг аварийных завершений | Hawk (hawk.so) | Российская Федерация |

Подробное описание технических средств хранения исходного текста, объектного кода и средств компиляции приведено в отдельном документе, подготовленном в соответствии с подпунктом «ж» пункта 11 Правил.

---

## 6. Условия предоставления поддержки

### 6.1. Гарантийная поддержка

Гарантийная поддержка предоставляется всем пользователям программного обеспечения безвозмездно в течение всего срока, пока соответствующая версия программного обеспечения находится на поддержке, и включает устранение дефектов и консультирование по каналам, указанным в пункте 2.1.

### 6.2. Срок поддержки версий

Поддерживается текущая версия программного обеспечения и предшествующая ей минорная версия. Пользователям более ранних версий предоставляется консультация по порядку обновления.

### 6.3. Расширенная поддержка

Для корпоративных пользователей на основании отдельного договора может предоставляться расширенная поддержка с сокращёнными сроками реакции, выделенным каналом связи и доработкой программного обеспечения под требования заказчика. Условия расширенной поддержки публикуются по адресу https://v0system.ru.

---

## 7. Контактная информация

| Параметр | Значение |
|---|---|
| Правообладатель | ________________________________ |
| ИНН | ____________ |
| Адрес | ________________________________ |
| Сайт | https://v0system.ru |
| Электронная почта службы поддержки | dev@v0system.ru |
| Телефон | +7 (___) ___-__-__ |

Настоящий документ размещён в открытом доступе по адресу https://v0system.ru/docs.