МТС объявила о запуске сервиса, который позволяет жителям Новосибирска с нарушением слуха пользоваться голосовой связью. Новость от 17 марта 2026 года — это не просто заметка для СМИ. За ней стоит тренд: информационные системы всё чаще проектируются с учётом потребностей людей с инвалидностью. Для студентов ИТ-направлений это готовый кейс, который можно перенести в дипломную работу. В этой статье разберём, как связать событие с темой ВКР, какие разделы наполнить конкретикой и где брать метрики для защиты.
Ключевая техническая суть — преобразование голоса в текст и обратно, маршрутизация вызовов, доступность сервиса через мобильное приложение или оператора. Для диплома это идеальный пример «системы с ограничениями»: требуются высокая надёжность, низкая задержка, адаптивный интерфейс. Если ваша тема касается разработки веб- или мобильного приложения, автоматизации процессов или работы с API — вы можете сослаться на этот кейс при обосновании актуальности.
Важно не просто написать «сервисы для слабослышащих актуальны», а показать, как ваша разработка решает конкретную задачу: распознавание речи, визуализация звуковых событий, умные уведомления. Ниже — три темы, которые легко «лечь» в стандартную структуру ВКР.
| Тема | Актуальность | Цель | Задачи (минимум) |
|---|---|---|---|
| Разработка мобильного приложения для распознавания речи у людей с нарушением слуха | Существующие сервисы либо платные, либо не адаптированы под русский язык | Создать прототип приложения с STT/TTS-модулем | 1) Обзор STT-движков; 2) Прототип интерфейса; 3) Интеграция с облачным API; 4) Нагрузочное тестирование |
| Архитектура сервиса субтитрирования телефонных разговоров | В статье МТС — операторский сервис, но для малого бизнеса нужна своя реализация | Спроектировать архитектуру сервиса на базе микросервисов | 1) Сравнение архитектурных стилей; 2) Схема интеграции с SIP; 3) Прототип очередей сообщений; 4) Расчет стоимости внедрения |
| Обеспечение доступности веб-интерфейса для людей с нарушением слуха | Требования ГОСТ и стандартов без «воды»: навигация без звука, визуальные подсказки | Улучшить показатели доступности существующего интерфейса | 1) Аудит по ISO/IEC 25010; 2) Разработка рекомендаций; 3) Прототип интерфейса; 4) Юзабилити-тестирование |
Обратите внимание: в каждой теме третья задача — интеграция с внешним API или сервисом. Это сильный ход на защите: вы показываете, что умеете работать с реальными ограничениями, а не только с учебным примером.
В разделе «Анализ предметной области» нужно показать, что вы изучили рынок и технологии. Сошлитесь на новость, затем сравните подходы:
Обязательно добавьте схему: как пользователь с нарушением слуха инициирует вызов, как его голос превращается в текст, а ответ — в речь. Эту схему можно нарисовать в ArchiMate или UML sequence diagram. На защите такие схемы ценятся больше, чем скриншоты кода.
В проектной главе переходите от теории к практике. Ссылку на статью оставляйте во введении, а здесь концентрируйтесь на артефактах:
Не забывайте про обработку ошибок. Например: пользователь говорит, система не распознала фразу. Какой сценарий? Повторное распознавание, уточняющий вопрос, перевод на оператора. Это проектная задача, и её нельзя пропускать.
Самый частый вопрос студентов: «Как измерить производительность в дипломе?». Для вашей темы подойдут три группы метрик:
| Аспект | Метрики | Инструмент |
|---|---|---|
| Качество распознавания | WER (Word Error Rate), точность на русском языке | Собственный тестовый набор, opensource-базы |
| Нагрузочное тестирование | RPS, время ответа, использование CPU/RAM | Apache JMeter, Locust, k6 |
| Доступность и отказоустойчивость | RTO/RPO, Uptime, SLO | Kubernetes, OpenTelemetry, Grafana |
В разделе «Тестирование» обязательно укажите, какие данные вы использовали. Где их взять? Откройте записи LiveJournal с субтитрами, возьмите аудиокниги с лицензией CC, синтезируйте тестовые фразы через TTS. Не нужно записывать голоса друзей — это сложно воспроизвести и вызывает вопросы на защите.
Оценку качества проведите по ISO/IEC 25010. Возьмите из стандарта характеристики « Пригодность», «Надёжность», «Производительность» и покажите, как ваша система удовлетворяет этим требованиям. Такая таблица — сильный аргумент для государственной экзаменационной комиссии.
Вы прокачаете навыки, которые прямо спрашивают на собеседованиях:
Ошибка 1. «Подмена терминов». Студент пишет «я разработал SaaS», но по факту делает простое веб-приложение на Django. Избегайте этого: если вы используете термин, то либо дайте определение и обоснуйте, почему ваша система соответствует модели SaaS, либо не вводите лишние сущности.
Ошибка 2. «Отсутствие метрик эффективности». Задачи в ВКР заканчиваются на «разработать алгоритм», но нет ни одного числа. Добавьте сравнение: «время ответа сервиса снизилось с 2,1 до 0,9 секунды» или «точность распознавания составила 92%». Конечно, эти цифры должны быть получены экспериментально, а не придуманы.
Ошибка 3. «Игнорирование требований ГОСТ при оформлении ТЗ». Если в задании на ВКР сказано «спроектировать ИС», вы обязаны написать ТЗ по ГОСТ 34.602-89. Не делайте ТЗ в свободной форме, чтобы не потерять баллы на проверке нормоконтроля.
Зависит от вашей специальности. Для «Программной инженерии» код — это базовое требование. Для «Бизнес-информатики» допустимо обойтись прототипом интерфейса и расчётом экономической эффективности. В любом случае, лучше иметь хотя бы минимальный рабочий фрагмент — это больше аргументов на защите. Если вы совсем не пишете код, усильте аналитическую часть и проектную документацию.
Используйте PlantUML или Draw.io. Вставьте диаграмму в приложение к ВКР и в текст — в главе «Проектирование». Для каждой диаграммы дайте текстовое описание на 2-3 абзаца. Ссылку на исходный код диаграммы (PlantUML) можно положить в репозиторий: это покажет навык работы с инструментами.
Варианты: открытые наборы данных (Common Voice от Mozilla, VoxForge), библиотеки с русской речью, синтез через онлайн-сервисы. Важно — указать в работе источники данных и приложить список файлов. Для «чистоты эксперимента» используйте рекомендации МТС по реальным сценариям — например, диалоги «врач-пациент» или «заказ еды».
Скопировать кейс МТС — плохая идея, это будет плагиат идеи. Но переработать его под свою задачу — норм: например, сделать сервис для конкретной организации, другого региона или с другим набором функций. Используйте статью как триггер для формулировки актуальности, а не как источник кода.
Если до защиты осталось 120 часов, а ВКР ещё не готова — не паникуйте. Бесплатная консультация поможет понять, что нужно доработать, а наши специалисты возьмут на себя техническую часть. Работаем с любой темой по прикладной информатике и программированию. Напишите нам, чтобы обсудить детали.
Источник: Жители Новосибирска с нарушением слуха смогут пользоваться голосовой связью (опубликовано 2026-03-17)