Разработка Информационно-справочной Системы Технической Поддержки Пользователей Телефонной Сети: Комплексное Руководство для Дипломной Работы с Учетом Современных Технологий и Нормативной Базы

В эпоху стремительного развития цифровых технологий и повсеместного распространения телекоммуникационных услуг, качество и оперативность технической поддержки становится не просто конкурентным преимуществом, а критически важным фактором лояльности клиентов и стабильности функционирования бизнеса. Показательно, что внедрение Help Desk систем способно обеспечить возврат инвестиций (ROI) до 300%, а онлайн-чат может увеличить доход на 48% за час разговора, демонстрируя прямую связь между эффективностью поддержки и экономическими показателями компании. В этом контексте, разработка современной информационно-справочной системы (ИСС) для технической поддержки пользователей телефонной сети перестает быть опцией и превращается в насущную необходимость, требующую глубокого аналитического подхода и применения передовых инженерных решений.

Настоящая дипломная работа посвящена созданию комплексного плана исследования, проектирования и реализации такой системы. Её целью является разработка всестороннего, академически обоснованного руководства, способного стать основой для создания эффективной ИСС. Для достижения этой цели были поставлены следующие задачи:

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

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

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

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

Глава 1. Анализ Предметной Области и Формирование Требований к Системе Технической Поддержки

Краткая аннотация

Эта глава посвящена всестороннему анализу текущих процессов технической поддержки пользователей телефонной сети. Мы выявим существующие проблемы, определим ключевые функциональные и нефункциональные требования к будущей информационно-справочной системе, основываясь на современных стандартах и лучших практиках ITIL 4. Цель — создать фундамент для проектирования системы, которая будет не просто решать текущие задачи, но и обладать потенциалом для дальнейшего развития и модернизации, что является критически важным для любой долгосрочной информационной системы.

Общие положения об информационно-справочных системах и системах технической поддержки

В современном информационном пространстве термин «информационно-справочная система» (ИСС) обозначает нечто большее, чем просто хранилище данных. Это сложный программный комплекс, предназначенный для аккумулирования, структурирования, хранения и оперативного предоставления пользователю разнообразной информации справочного характера. Ключевыми характеристиками ИСС являются иерархическая организация материала и возможность быстрого поиска информации по множеству параметров. Отличительной чертой ИСС является их пассивность в отношении принятия решений: они не осуществляют завершающей обработки или выработки решений, а лишь служат надежным источником релевантной информации, позволяя пользователю самостоятельно формировать выводы.

ИСС могут быть классифицированы по типу хранимой информации:

• Документальные ИСС управляют документами в их естественном виде (например, статьи, отчеты).
• Документографические ИСС предоставляют информацию о документах (метаданные: автор, название, год публикации).
• Фактографические ИСС хранят конкретные факты и данные (например, характеристики оборудования, тарифные планы).
• Полнотекстовые ИСС позволяют осуществлять поиск по всему содержимому текстов документов.

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

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

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

Рассмотрим детализацию уровней технической поддержки:

Таблица 1.1. Уровни технической поддержки и их характеристики

Уровень поддержки	Основные функции	Компетенции персонала	Целевое время решения
Первая линия (L1)	Прием, фильтрация, классификация, распределение заявок; решение простых запросов (сброс пароля, установка ПО, проверка соединений).	Базовые знания продукта/услуги, навыки коммуникации, работа с типовыми скриптами и базой знаний.	5-15 минут
Вторая линия (L2)	Обработка сложных проблем, требующих диагностики; удаленный доступ к системам клиента; эскалация запросов в L3.	Глубокие знания систем, ПО, оборудования; навыки диагностики и поиска неочевидных решений.	От нескольких часов до нескольких дней
Третья линия (L3)	Решение самых сложных технических задач: исправление программных ошибок, оптимизация, настройка сетей; взаимодействие с разработчиками.	Высокая квалификация, уникальные знания, экспертиза в конкретных областях, навыки отладки и доработки.	От нескольких дней до нескольких недель
Четвертая линия (L4)	Решение проблем, связанных с продуктами или оборудованием сторонних производителей; взаимодействие с внешними вендорами.	Специализированные знания о продуктах сторонних поставщиков, доступ к их ресурсам и документации.	Зависит от сложности и регламента вендора

Специфика организации технической поддержки для пользователей телефонной сети добавляет свои нюансы. Здесь ключевое значение приобретают:

• Обработка звонков: Интеграция с АТС (автоматической телефонной станцией) для автоматического определения номера, регистрации входящих вызовов, ведения истории общения и распределения звонков между операторами.
• Особенности клиентских запросов: Это могут быть как типовые вопросы (настройка роутера, выбор тарифного плана, проверка баланса), так и более сложные проблемы, связанные с качеством связи, обрывами, неработающим оборудованием. Система должна быть способна быстро идентифицировать тип запроса и предоставить релевантную информацию или маршрутизировать его к соответствующему специалисту.
• Учет оборудования: Для эффективной поддержки телефонной сети критически важно иметь информацию об используемом оборудовании клиента (модели телефонов, роутеров, абонентских терминалов), его конфигурации и истории обслуживания.

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

Анализ текущего состояния и проблем технической поддержки (AS-IS модель)

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

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

• Службу первой линии (колл-центр): Операторы, принимающие входящие звонки, обрабатывающие запросы через чат или электронную почту. Их основная задача – первичная диагностика, предоставление типовых решений и эскалация сложных случаев.
• Службу второй линии (технические специалисты): Более квалифицированные инженеры, способные решать проблемы, требующие глубоких знаний оборудования, ПО и сетевых протоколов.
• Отдел эксплуатации/инфраструктуры (третья линия): Разработчики, сетевые инженры, специалисты по базам данных, которые занимаются устранением корневых причин сложных инцидентов, исправлением ошибок в системе, модернизацией инфраструктуры.

Бизнес-процесс обработки обращений в традиционной модели часто выглядит следующим образом:

1. Прием обращения: Клиент звонит в колл-центр, отправляет email или сообщение в чат. Оператор вручную регистрирует обращение, пытаясь определить его тип и срочность.
2. Первичная диагностика: Оператор первой линии пытается решить проблему, используя внутренние инструкции или собственный опыт.
3. Поиск информации: Оператор тратит время на поиск необходимой информации в разрозненных источниках (файлы Excel, текстовые документы, старые базы данных, личные заметки).
4. Решение или эскалация: Если проблема типовая и решение найдено, оператор предоставляет его клиенту. В противном случае, запрос эскалируется на вторую линию.
5. Повторная регистрация/передача: При эскалации часто происходит повторное описание проблемы, так как информация не всегда передается полноценно или в стандартизированном виде. Клиенту приходится повторять свои данные и детали обращения.
6. Решение на L2/L3: Специалисты более высокого уровня работают над проблемой.
7. Закрытие обращения: После решения проблемы, обращение закрывается, иногда с кратким комментарием о выполненных действиях.

Такой подход, как показывает практика, неизбежно приводит к узким местам и проблемам:

• Рутинные операции и неэффективность: Операторы тратят значительное время на ручной ввод данных, поиск информации в неструктурированных источниках, что замедляет обслуживание и снижает производительность.
• Проблемы с оперативностью и качеством обслуживания: Длительное время ожидания, повторные обращения по одной и той же проблеме, неполная или противоречивая информация, предоставляемая разными операторами, приводят к снижению удовлетворенности клиентов. Отсутствие централизованной базы знаний приводит к зависимости от личного опыта отдельных сотрудников.
• Дублирование информации и потеря данных: Информация об обращениях может храниться в разных системах или документах, что затрудняет ее консолидацию, приводит к дублированию ввода и риску потери важных деталей. Клиенту приходится повторять информацию нескольким операторам.
• Неэффективное распределение нагрузки и эскалация: Отсутствие четких правил маршрутизации запросов приводит к тому, что сложные проблемы могут долго задерживаться на первой линии, а простые – неоправданно эскалироваться.
• Сложность анализа и контроля: Без централизованной системы невозможно эффективно анализировать количество обращений, среднее время решения, выявлять наиболее частые проблемы и оценивать производительность команды. Это затрудняет стратегическое планирование и совершенствование сервиса.
• Устаревшее техническое оснащение: Использование устаревшего или разрозненного программного обеспечения, отсутствие интеграции между различными системами (например, АТС и CRM) значительно тормозит процессы и ограничивает возможности автоматизации.

Анализ текущего технического оснащения может показать, что служба поддержки использует:

• Базовые CRM-системы для ведения клиентской базы, но без глубокой интеграции с процессами техподдержки.
• Электронную почту и телефон для коммуникации.
• Файловые хранилища (общие папки) для документации и инструкций.
• Различные таблицы для учета заявок, что крайне неэффективно.

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

Формирование функциональных и нефункциональных требований к ИСС технической поддержки (TO-BE модель)

На основе проведенного анализа текущего состояния и выявленных проблем, а также с учетом лучших практик и стандартов, мы можем приступить к формированию целевой модели (TO-BE) и детальной спецификации требований к будущей информационно-справочной системе технической поддержки пользователей телефонной сети. Этот этап является критически важным, поскольку именно он определяет функционал, качество и эксплуатационные характеристики разрабатываемого решения.

Требования к системе традиционно делятся на функциональные и нефункциональные.

Функциональные требования (ФТ) описывают, что система должна делать, то есть ее конкретные действия, поведение и возможности. Для ИСС технической поддержки пользователей телефонной сети, ФТ будут включать:

1. Регистрация и классификация обращений:
   • Автоматический и ручной прием обращений из различных каналов (телефон, email, онлайн-чат, личный кабинет).
   • Автоматическая идентификация клиента по номеру телефона/логину.
   • Присвоение уникального номера каждому обращению.
   • Классификация обращений по типу проблемы (например, проблемы с подключением, настройкой оборудования, тарифами, качеством связи), приоритету (критический, высокий, средний, низкий) и статусу (открыто, в работе, ожидает клиента, решено, закрыто).
   • Возможность добавления подробного описания проблемы, прикрепления файлов (скриншоты, логи).
2. Управление базой знаний (БЗ):
   • Централизованное хранилище типовых решений, инструкций, FAQ, регламентов, технических спецификаций оборудования.
   • Модуль для создания, редактирования и публикации статей БЗ с возможностью прикрепления мультимедийных материалов.
   • Система полнотекстового и категориального поиска по БЗ с учетом релевантности.
   • Механизм оценки полезности статей БЗ пользователями и операторами.
   • Возможность автоматического предложения релевантных статей оператору при регистрации обращения.
3. Автоматическая маршрутизация и эскалация:
   • Настройка правил автоматической маршрутизации обращений к соответствующим специалистам или отделам на основе типа проблемы, приоритета, загруженности операторов.
   • Механизм автоматической эскалации обращений при нарушении SLA (Service Level Agreement) или отсутствии решения в установленные сроки.
   • Настройка уровней эскалации (L1 → L2 → L3).
4. Управление операторами и рабочими группами:
   • Назначение обращений конкретным операторам или группам.
   • Отслеживание статуса и прогресса решения по каждому обращению.
   • Возможность передачи обращения между операторами с сохранением всей истории.
   • Управление доступом к функционалу и данным в завис��мости от роли оператора.
5. Личный кабинет пользователя:
   • Доступ к информации о своих обращениях, их статусе и истории.
   • Возможность создания новых обращений и отслеживания их статуса.
   • Доступ к публичной части базы знаний.
   • Возможность оценки качества обслуживания и закрытия обращения.
6. Формирование отчетов и аналитика:
   • Генерация отчетов по количеству обращений (общее, по типам, по статусам), среднему времени решения, загруженности операторов, соблюдению SLA.
   • Визуализация данных в виде графиков и диаграмм для анализа производительности и выявления проблемных зон.

Нефункциональные требования (НФТ) определяют, как система должна работать, ее качества и стандарты. Они играют не менее важную роль, обеспечивая эффективность, надежность и безопасность. Примеры НФТ для нашей ИСС:

1. Производительность:
   • Система должна обрабатывать до 1000 запросов в час.
   • Время отклика на действия пользователя (открытие страницы, поиск в БЗ) не должно превышать 2 секунд для 95% запросов.
   • Поддержка не менее 100 одновременно работающих операторов и 500 одновременных пользователей в личном кабинете.
2. Безопасность:
   • Использование многофакторной аутентификации для доступа операторов.
   • Шифрование всех передаваемых и хранимых персональных данных (например, 256-битное шифрование AES).
   • Разграничение прав доступа на основе ролей (администратор, оператор L1, L2, L3, пользователь).
   • Защита от распространенных веб-уязвимостей (SQL-инъекции, XSS, CSRF).
   • Регулярное резервное копирование данных и возможность их быстрого восстановления.
3. Масштабируемость:
   • Возможность горизонтального масштабирования для увеличения количества пользователей и объема данных без значительного снижения производительности.
   • Архитектура должна предусматривать возможность добавления новых модулей и функционала.
4. Надежность:
   • Обеспечение бесперебойной работы системы (доступность) на уровне не ниже 99.9% в месяц.
   • Система должна быть устойчива к сбоям отдельных компонентов (отказоустойчивость).
   • Механизмы логирования ошибок и автоматического восстановления после сбоев.
5. Удобство использования (Usability):
   • Интуитивно понятный и эргономичный пользовательский интерфейс для операторов и клиентов.
   • Минимальное количество шагов для выполнения типовых операций.
   • Наличие контекстной справки и обучающих материалов.
6. Поддерживаемость:
   • Модульная архитектура, упрощающая внесение изменений и устранение ошибок.
   • Наличие исчерпывающей технической документации.
   • Использование общепринятых стандартов кодирования и документирования.

Применение стандартов ГОСТ 34 серии и IEEE для спецификации требований обеспечит методологическую корректность и полноту технического задания. В частности, ГОСТ 34.602-2020 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы» и IEEE 830-1998 «Рекомендуемая практика по разработке спецификаций требований к программному обеспечению» станут основой для структурирования и детализации всех требований.

Особое внимание следует уделить учету принципов ITIL 4 при формировании требований к сервису. ITIL 4, будучи современной библиотекой лучших практик управления ИТ-услугами, акцентирует внимание на создании ценности для клиента. Семь руководящих принципов ITIL 4 станут ориентирами:

• Фокусируйтесь на ценности: Каждая функция системы должна быть направлена на создание ценности для конечного пользователя и бизнеса.
• Начинайте с текущего: Разрабатываемая система должна интегрироваться с существующими процессами и инфраструктурой, а не замещать их полностью без анализа.
• Двигайтесь постепенно с обратной связью: Внедрение функционала должно происходить итерационно, с постоянным сбором обратной связи для корректировки и улучшения.
• Сотрудничайте и продвигайте прозрачность: Система должна обеспечивать прозрачность всех процессов и способствовать сотрудничеству между отделами.
• Мыслите и работайте целостно: Рассматривать систему как часть общей экосистемы, учитывая ее влияние на другие ИТ-сервисы и бизнес-процессы.
• Используйте автоматизацию и оптимизируйте: Максимально автоматизировать рутинные задачи, что позволит сотрудникам сосредоточиться на более сложных запросах и повысит оперативность.
• Не пренебрегайте простотой и практичностью: Избегать излишней сложности, отдавая предпочтение простым и эффективным решениям.

Внедрение Help Desk систем, как показывают исследования, способно обеспечить возврат инвестиций (ROI) до 300%. Онлайн-чат может увеличить доход на 48% за час разговора, а общий коэффициент конверсии — на 40%. Кроме того, база знаний в Help Desk системе может сократить входящие звонки в поддержку на 5%. Эти данные подчеркивают экономическую целесообразность и значимость детализированного подхода к формированию требований, который ляжет в основу успешного проекта.

Глава 2. Проектирование Архитектуры и Информационной Модели Системы

Краткая аннотация

Эта глава посвящена созданию логической и физической архитектуры информационной системы. Мы углубимся в методы моделирования, такие как UML и ER-диаграммы, рассмотрим ключевые архитектурные паттерны и принципы проектирования баз данных, а также выберем оптимальные программно-аппаратные средства для реализации. Цель — заложить прочный и масштабируемый фундамент для будущей ИСС, обеспечивая ее эффективность и долговечность.

Методы и модели системного анализа для проектирования ИС

Проектирование информационно-справочной системы (ИСС) технической поддержки является комплексной задачей, требующей систематизированного подхода. На этом этапе мы используем мощный арсенал методов и моделей системного анализа, позволяющих визуализировать, структурировать и детализировать будущую систему до ее программной реализации.

Одним из наиболее распространенных и мощных инструментов является UML (Unified Modeling Language – унифицированный язык моделирования). Это де-факто отраслевой стандарт, используемый для графического описания бизнес-процессов, архитектуры программного обеспечения и ИТ-инфраструктуры. UML включает 14 типов диаграмм, которые можно разделить на структурные и поведенческие.

Для нашей ИСС мы сфокусируемся на наиболее релевантных диаграммах:

1. Диаграммы прецедентов (Use Case Diagrams): Это отправная точка для понимания функциональности системы. Они демонстрируют высокоуровневую модель функционирования системы во взаимодействии с внешней средой, определяя, что система должна делать с точки зрения пользователей (акторов). Для ИСС техподдержки это могут быть такие прецеденты, как «Зарегистрировать обращение», «Найти решение в базе знаний», «Эскалировать запрос», «Просмотреть статус обращения» (для клиента) и т.д. Эти диаграммы помогают определить границы системы и ее основные функции.
2. Диаграммы классов (Class Diagrams): Эти структурные диаграммы описывают статическую структуру системы, показывая классы, их атрибуты, методы и отношения между ними (ассоциация, агрегация, композиция, наследование). Для ИСС они будут моделировать ключевые сущности, такие как «Обращение», «Клиент», «Оператор», «Статья базы знаний», «Оборудование», «Тарифный план». Диаграммы классов служат основой для проектирования объектно-ориентированной структуры кода и базы данных.
3. Диаграммы последовательности (Sequence Diagrams): Эти поведенческие диаграммы иллюстрируют взаимодействие объектов во времени, показывая порядок вызова методов и передачу сообщений между ними. Они критически важны для детализации динамического поведения системы, например, для демонстрации процесса регистрации обращения, поиска решения в БЗ или процесса эскалации запроса. Диаграммы последовательности помогают выявить потенциальные проблемы во взаимодействии компонентов и оптимизировать потоки данных.

Помимо UML, для проектирования базы данных незаменимым инструментом является ER-диаграмма (схема «сущность-связь», ERD). ERD — это разновидность блок-схемы, которая наглядно отображает, как различные «сущности» (реальные или абстрактные объекты, имеющие значение для системы) связаны между собой. Чаще всего ER-диаграммы используются для проектирования и отладки реляционных баз данных.

ER-моделирование включает три уровня детализации:

• Концептуальная модель данных: Высокоуровневое представление сущностей и их связей, независимое от конкретной СУБД. Она фокусируется на бизнес-потребностях.
• Логическая модель данных: Детализирует концептуальную модель, добавляя атрибуты для каждой сущности, определяя первичные и внешние ключи, типы связей (один-к-одному, один-ко-многим, многие-ко-многим). Эта модель все еще независима от СУБД, но близка к ее структуре.
• Физическая модель данных: Конкретное представление логической модели, адаптированное под выбранную СУБД, с указанием типов данных, индексов, ограничений, и других специфических параметров.

Основные концепции ER-модели:

• Сущности (Entity): Представляются прямоугольниками (например, «Клиент», «Обращение»).
• Атрибуты (Attribute): Характеристики сущностей, представляются овалами (например, для «Клиента»: ФИО, номер телефона, адрес).
• Связи (Relationship): Описывают взаимосвязи между сущностями, представляются ромбами (например, «Клиент» создает «Обращение»).

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

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

Для нашей ИСС техподдержки будут применены следующие паттерны:

1. Многослойная (n-tier) архитектура: Это классический и широко используемый паттерн, разделяющий функциональность приложения на логические слои. Типичные слои:
   • Уровень представления (Presentation Layer): Пользовательский интерфейс (Frontend), отвечающий за отображение информации и взаимодействие с пользователем.
   • Уровень бизнес-логики (Business Logic Layer): Содержит основную логику приложения, обрабатывает запросы, применяет правила, взаимодействует с уровнем данных.
   • Уровень данных (Data Access Layer): Отвечает за взаимодействие с базой данных, CRUD-операции.

   Это разделение облегчает понимание системы, упрощает тестирование каждого слоя независимо, а также повышает гибкость и поддерживаемость, позволяя изменять один слой без значительного влияния на другие.

2. Модель-Представление-Контроллер (MVC): Этот паттерн является частным случаем многослойной архитектуры и широко применяется в веб-разработке. Он разделяет приложение на три взаимосвязанных компонента:
   • Модель (Model): Представляет данные и бизнес-логику приложения. Она не зависит от представления и контроллера.
   • Представление (View): Отвечает за отображение данных пользователю. Оно получает данные от модели.
   • Контроллер (Controller): Обрабатывает ввод пользователя, взаимодействует с моделью для обновления данных и с представлением для их отображения.

   MVC способствует разделению ответственности, делая код более организованным и легким для расширения.

Рассмотрение современных архитектурных подходов также является важным для обеспечения гибкости и масштабируемости, особенно если в будущем планируется расширение функционала или интеграция с другими сервисами. Как иначе обеспечить адаптацию к быстро меняющимся требованиям рынка?

• Чистая архитектура (Clean Architecture), или «Onion Architecture«: Этот подход, популяризированный Робертом Мартином («Дядюшкой Бобом»), подчеркивает разделение функциональности на концентрические слои, где модель предметной области находится в центре. Внешние слои (интерфейсы пользователя, базы данных, веб-сервисы) зависят от внутренних, но не наоборот. Это обеспечивает высокую независимость бизнес-логики от внешних технологий, упрощает тестирование и делает систему более устойчивой к изменениям. Для ИСС это означает, что основная логика обработки обращений и управления БЗ будет изолирована от конкретных веб-фреймворков или СУБД.
• Событийно-ориентированная архитектура (Event-driven Architecture): Основана на асинхронной обработке событий. Компоненты системы взаимодействуют через публикацию и подписку на события. Например, после регистрации нового обращения («ОбращениеСоздано»), другие модули могут реагировать на это событие (например, отправить уведомление оператору, обновить статистику). Этот паттерн повышает масштабируемость, отказоустойчивость и ослабляет связность компонентов, что критично для систем, требующих высокой степени параллелизма и интеграции.

Выбор конкретных архитектурных решений будет зависеть от детального анализа требований к масштабируемости, сложности системы и команды разработки, но применение этих принципов обеспечит прочную основу для построения эффективной и развиваемой ИСС.

Проектирование базы данных информационной системы

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

Принципы проектирования реляционных баз данных основаны на математической теории реляционных моделей и нацелены на минимизацию избыточности данных, обеспечение их целостности и согласованности. Ключевые принципы включают:

• Правильное определение таблиц: Каждая таблица должна представлять собой уникальный объект или понятие из предметной области (например, «Клиенты», «Обращения», «Операторы», «Оборудование»).
• Целостность данных: Поддержание достоверности и согласованности данных. Это включает:
  • Целостность сущностей: Каждая строка в таблице должна быть уникальной (через первичный ключ, PK).
  • Ссылочная целостность: Внешние ключи (FK) должны ссылаться только на существующие первичные ключи в связанных таблицах.
• Атомарность значений: Каждая ячейка таблицы должна содержать только одно, неделимое (атомарное) значение.
• Требования ACID: Набор свойств, гарантирующих надежную обработку транзакций:
  • Atomicity (Атомарность): Транзакция либо выполняется полностью, либо не выполняется вовсе.
  • Consistency (Согласованность): Транзакция переводит БД из одного корректного состояния в другое.
  • Isolation (Изолированность): Параллельно выполняющиеся транзакции не влияют друг на друга.
  • Durability (Долговечность): Результаты выполненной транзакции сохраняются даже при сбоях системы.

Выбор системы управления базами данных (СУБД) является фундаментальным решением. С учетом требований к масштабируемости, безопасности и надежности, для веб-ориентированной ИСС техподдержки оптимальными кандидатами являются:

• PostgreSQL: Мощная, объектно-реляционная СУБД с открытым исходным кодом, известная своей надежностью, расширяемостью, поддержкой сложных запросов и широким набором функционала (например, поддержка JSONB, географических данных). Идеально подходит для систем, где требуется высокая целостность данных и гибкость.
• MySQL: Также популярная РБД с открытым исходным кодом, широко используемая в веб-разработке. Отличается высокой производительностью для чтения данных, простотой в использовании и обширной экосистемой. Хороший выбор для приложений с большим количеством запросов на чтение.

Сравнительный анализ:
PostgreSQL часто выбирают для более сложных и критически важных приложений, где важна высокая степень соответствия стандартам SQL, расширяемость и поддержка транзакций. MySQL может быть предпочтительнее для более простых проектов или при необходимости высокой скорости чтения данных. Для нашей ИСС, учитывая необходимость хранения разнообразных данных (тексты обращений, файлы, ��ользовательская информация, данные оборудования), а также потенциальную потребность в аналитике, PostgreSQL будет более предпочтительным выбором.

Нормализация данных — это процесс организации полей и таблиц реляционной базы данных для минимизации избыточности данных и исключения аномалий вставки, обновления и удаления. Это многоэтапный процесс приведения структуры данных к «нормальным формам».

• Первая нормальная форма (1НФ):
  • Требование: Каждая ячейка таблицы должна содержать только одно атомарное значение. Все данные в одной колонке должны быть одного типа. Каждая запись (строка) в таблице должна быть уникальной.
  • Пример: Если в поле «Контактные телефоны» клиента хранится несколько номеров через запятую, это нарушает 1НФ. Необходимо создать отдельную таблицу «Телефоны клиентов», где каждый номер будет отдельной записью, связанной с клиентом.
• Вторая нормальная форма (2НФ):
  • Требование: Таблица должна находиться в 1НФ, и каждая неключевая колонка должна полностью зависеть от всего первичного ключа. Отсутствие частичных зависимостей.
  • Пример: Если первичный ключ состоит из двух столбцов (например, (ИД_{Оператора}, ИД_{Обращения})), а Имя_{Оператора} зависит только от ИД_{Оператора} (частичная зависимость), то Имя_{Оператора} должно быть перенесено в отдельную таблицу «Операторы».
• Третья нормальная форма (3НФ):
  • Требование: Таблица должна находиться во 2НФ, и не должно быть транзитивных функциональных зависимостей, то есть неключевые столбцы не должны зависеть от других неключевых столбцов.
  • Пример: В таблице «Обращения», если есть поле ИД_{Категории} и Название_{Категории}, и Название_{Категории} зависит от ИД_{Категории}, а не от первичного ключа таблицы «Обращения», то Название_{Категории} должно быть перенесено в отдельную таблицу «Категории обращений».

Разработка логической и физической структуры БД — это кульминация процесса проектирования. Она включает:

• Определение таблиц: «Клиенты», «Операторы», «Обращения», «КатегорииОбращений», «СтатусыОбращений», «БазаЗнаний», «ОборудованиеКлиента», «ТарифныеПланы», «ЛогиДействий» и т.д.
• Определение столбцов (атрибутов) для каждой таблицы: ИД_{Клиента} (PK), ФИО, НомерТелефона, Адрес, Email для таблицы «Клиенты». ИД_{Обращения} (PK), ИД_{Клиента} (FK), ИД_{Категории} (FK), ИД_{Оператора} (FK), Тема, Описание, ДатаСоздания, ДатаЗакрытия, Приоритет, Статус для таблицы «Обращения».
• Определение типов данных: INTEGER, VARCHAR(255), TEXT, BOOLEAN, DATE, TIMESTAMP и т.д.
• Установка первичных и внешних ключей: Для обеспечения целостности и связей между таблицами.
• Создание индексов: Для ускорения поиска и фильтрации данных по часто используемым полям.
• Ограничения (constraints): NOT NULL, UNIQUE, CHECK для обеспечения корректности данных.

Особое внимание будет уделено специфике хранения информации о пользователях телефонной сети, их оборудовании (модели роутеров, абонентских устройств, их MAC-адреса, прошивки), тарифных планах и истории обслуживания. Это позволит операторам иметь полный контекст обращения клиента. Проектирование БД — это трудоемкий процесс, требующий глубокого знания предметной области и учета всех нюансов для обеспечения масштабируемости и производительности.

Выбор программно-аппаратных средств и технологий реализации

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

Обоснование выбора Frontend-технологий:
Frontend — это та часть системы, с которой напрямую взаимодействует пользователь. Она отвечает за пользовательский интерфейс и его интерактивность. Основные компоненты Frontend-разработки включают:

• HTML (HyperText Markup Language): Язык разметки для создания структуры веб-страниц (заголовки, абзацы, таблицы, формы). Это основа любого веб-приложения.
• CSS (Cascading Style Sheets): Язык для стилизации веб-страниц (цвета, шрифты, отступы, расположение элементов). Он отвечает за внешний вид приложения.
• JavaScript: Язык программирования, который обеспечивает интерактивность веб-страниц. Он позволяет создавать динамические элементы, обрабатывать события пользователя, отправлять запросы на сервер без перезагрузки страницы.

В современных условиях чистый JavaScript редко используется для сложных веб-приложений. На помощь приходят современные фреймворки и библиотеки, которые значительно упрощают и ускоряют разработку, обеспечивая модульность, повторное использование компонентов и более эффективное управление состоянием приложения.

• React (библиотека JavaScript от Facebook): Чрезвычайно популярен благодаря своей компонентной модели, виртуальному DOM для оптимизации производительности и обширной экосистеме. Идеально подходит для создания сложных, интерактивных пользовательских интерфейсов.
• Vue.js (прогрессивный фреймворк): Известен своей простотой изучения, гибкостью и высокой производительностью. Хорошо подходит как для небольших проектов, так и для крупных одностраничных приложений.
• Angular (фреймворк от Google): Мощный и полноценный фреймворк с полной экосистемой, включающей инструменты для маршрутизации, управления состоянием, тестирования. Идеален для крупных корпоративных приложений.

Для нашей ИСС, учитывая потребность в богатом и отзывчивом пользовательском интерфейсе для операторов и клиентов, а также возможность дальнейшего расширения функционала, рекомендуется использовать React или Vue.js. Оба варианта предлагают отличные возможности для создания компонентных, масштабируемых и производительных интерфейсов. React может быть предпочтительнее за счет большей популярности и, соответственно, более широкой базы специалистов и готовых решений.

Обоснование выбора Backend-технологий:
Backend — это «сердце» системы, отвечающее за бизнес-логику, взаимодействие с базой данных, аутентификацию, авторизацию и API-интерфейсы. Выбор Backend-технологий определяется требованиями к производительности, масштабируемости, безопасности и экосистеме.

• Python (Django, Flask): Python — универсальный язык, известный своей читаемостью и обширными библиотеками. Django — высокоуровневый фреймворк, обеспечивающий быструю разработку надежных веб-приложений по принципу «батарейки в комплекте». Flask — легковесный микрофреймворк для более гибкой разработки. Отлично подходит для систем, где важна скорость разработки и наличие сильного сообщества.
• Node.js (Express.js): Позволяет использовать JavaScript как на Frontend, так и на Backend, что упрощает разработку и позволяет команде специализироваться на одном языке. Express.js — минималистичный и гибкий фреймворк для Node.js, идеальный для построения API.
• PHP (Laravel): PHP остается одним из самых популярных языков для веб-разработки. Laravel — элегантный и мощный фреймворк, который ускоряет разработку, предоставляя множество готовых компонентов (ORM, маршрутизация, аутентификация).
• Java (Spring): Java и фреймворк Spring — это мощное сочетание для создания высокопроизводительных, масштабируемых и безопасных корпоративных приложений. Часто используется в крупных системах.

Для ИСС технической поддержки, требующей обработки значительного объема данных, высокой производительности и масштабируемости, а также возможности интеграции с различными сервисами, оптимальным выбором может быть Python с фреймворком Django или Node.js с Express.js. Django предлагает быструю разработку с акцентом на безопасность и ORM, что упрощает работу с базой данных. Node.js с Express.js отлично подходит для создания высокопроизводительных API и микросервисов, особенно если Frontend также на JavaScript.

Анализ и выбор современных веб-фреймворков (Fullstack/SSR):
Существуют также фреймворки, которые позволяют строить полнофункциональные веб-приложения, объединяя возможности Frontend и Backend, или предлагая гибридные подходы (например, Server-Side Rendering — SSR).

• Next.js (фреймворк React): Позволяет создавать полнофункциональные React-приложения с SSR, статическим генерированием и серверными компонентами. Это значительно улучшает производительность, SEO и общее пользовательское впечатление. Идеален для построения современных, быстрых и масштабируемых веб-приложений.
• Hapi: Фреймворк для Node.js, разработанный с акцентом на конфигурацию, безопасность и совместную работу больших команд. Отлично подходит для создания надежных API и веб-сервисов.
• Meteor: Полноценный веб-фреймворк, ориентированный на Frontend, но с поддержкой TypeScript и возможностью создания веб-, мобильных и настольных приложений. Позволяет значительно ускорить разработку благодаря реактивности и интеграции с базами данных в реальном времени.

Для обеспечения максимальной производительности, гибкости и соответствия современным стандартам веб-разработки, особенно с учетом потребностей в быстром поиске и отображении информации, Next.js является очень перспективным выбором. Он позволяет использовать React для Frontend, но при этом эффективно обрабатывать данные на сервере, что снижает нагрузку на клиентскую сторону и улучшает SEO, что может быть важно для публичной части базы знаний.

Таким образом, рекомендуемый стек технологий для ИСС технической поддержки может выглядеть следующим образом:

• Frontend: React (с Next.js для SSR и оптимизации).
• Backend: Python (Django) или Node.js (Express.js) для API-сервисов.
• База данных: PostgreSQL.

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

Глава 3. Реализация, Тестирование и Внедрение Информационной Системы

Краткая аннотация

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

Этапы разработки и реализации программного обеспечения

Разработка любого программного обеспечения, особенно такой сложной системы, как информационно-справочная система технической поддержки, представляет собой структурированный процесс, который проходит через определенные стадии. Этот процесс часто называют жизненным циклом разработки программного обеспечения (ЖЦПО). Классический полный жизненный цикл включает следующие основные этапы:

1. Планирование (Planning): На этом этапе определяются цели проекта, его объем, ресурсы, сроки, бюджет, а также оцениваются риски. Здесь формируются бизнес-требования, проводятся исследования рынка и конкурентов, создается предварительный план проекта.
2. Анализ (Analysis): Глубокое изучение предметной области, сбор и детализация требований к системе (как функциональных, так и нефункциональных). Создаются модели «как есть» (AS-IS) и «как должно быть» (TO-BE), формируется техническое задание.
3. Проектирование (Design): Разработка архитектуры системы, проектирование базы данных, пользовательского интерфейса, API, выбор технологий. На этом этапе создаются UML-диаграммы, ER-модели, спецификации модулей.
4. Кодирование (Coding/Implementation): Непосредственная разработка программного обеспечения в соответствии с проектной документацией. Это включает написание кода, интеграцию модулей, настройку СУБД.
5. Тестирование (Testing): Проверка разработанного ПО на соответствие требованиям, выявление и устранение ошибок. Подробнее об этом будет рассказано в следующем подразделе.
6. Развертывание (Deployment): Установка и настройка системы на рабочих серверах, предоставление доступа конечным пользователям.
7. Мониторинг и Сопровождение (Monitoring & Maintenance): Эксплуатация системы, отслеживание ее производительности, устранение возникающих проблем, обновление функционала, обеспечение безопасности.

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

• Каскадная (Waterfall) модель: Это линейный, последовательный подход, где каждый этап завершается до начала следующего. Документация создается на каждом этапе, и изменения вносятся сложно.
  • Обоснование выбора: Для дипломной работы, которая имеет четко ограниченные сроки и объем, и где требования достаточно стабильны на старте, каскадная модель может быть вполне приемлема. Она обеспечивает строгий контроль над документацией и предсказуемость сроков при условии, что требования не меняются.
• Гибкие (Agile) методологии (например, Scrum): Итеративный и инкрементальный подход, ориентированный на быструю адаптацию к изменениям. Разработка ведется короткими циклами (спринтами), в конце каждого из которых выпускается рабочая версия продукта.
  • Обоснование выбора: Если дипломная работа предполагает реальную разработку с возможностью изменения требований и активного взаимодействия с заказчиком (например, для реального внедрения в компании), Agile/Scrum будет более эффективным. Он позволяет быстро реагировать на обратную связь и выпускать ценный функционал по частям.

Для дипломной работы, которая часто является формализованным проектом с заранее определенными целями и объемом, каскадная модель с элементами итеративности на этапах проектирования и кодирования может быть оптимальной. Однако важно понимать преимущества Agile для реальных коммерческих проектов.

Использование подходов непрерывной интеграции (CI) и непрерывной доставки/развертывания (CD) является современным стандартом в разработке ПО. Они направлены на автоматизацию процессов сборки, тестирования и развертывания кода, значительно повышая оперативность и качество продукта:

• Непрерывная интеграция (CI): Практика, при которой разработчики часто интегрируют свой код в общую репозиторию (например, Git). Каждое изменение автоматически проверяется с помощью автоматизированных тестов. Это помогает обнаруживать и исправлять ошибки интеграции на ранних стадиях, минимизируя конфликтные ситуации.
• Непрерывная доставка (CD — Continuous Delivery): Расширение CI, при котором код, прошедший все тесты, автоматически подготавливается к развертыванию. Это означает, что в любой момент времени готовый к работе код может быть развернут в тестовой или даже продуктивной среде.
• Непрерывное развертывание (CD — Continuous Deployment): Автоматическое развертывание каждого успешно протестированного изменения в продуктивную среду без ручного вмешательства.

Преимущества CI/CD:

• Повышение оперативности: Ускоряется цикл от разработки до выпуска продукта.
• Улучшение качества: Раннее обнаружение ошибок и автоматизированное тестирование.
• Снижение рисков: Меньше вероятность человеческих ошибок при развертывании.
• Упрощение совместной работы: Разработчики могут интегрировать свой код чаще и быть уверенными в его работоспособности.

Для дипломной работы, даже если полноценный CI/CD пайплайн не будет реализован, понимание этих принципов и их описание в работе покажет глубокое знание современных практик разработки. Можно ограничиться автоматизацией сборки и запуска модульных тестов при каждом измене��ии кода.

Тестирование и обеспечение качества программного обеспечения

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

Виды тестирования, применимые к ИСС:

1. Модульное (Unit) тестирование: Проверка отдельных наименьших частей кода (модулей, функций, классов) на корректность их работы в изоляции. Проводится разработчиками.
   • Пример: Тестирование функции создания нового обращения, функции поиска в базе знаний.
2. Интеграционное (Integration) тестирование: Проверка взаимодействия между различными модулями или компонентами системы. Цель — выявить ошибки, возникающие при их совместной работе.
   • Пример: Тестирование процесса, когда пользователь создает обращение через личный кабинет, и оно корректно отображается в интерфейсе оператора и записывается в базу данных.
3. Функциональное (Functional) тестирование: Проверка соответствия системы функциональным требованиям, то есть того, что система должна делать. Тестировщики проверяют, как система выполняет заявленные бизнес-функции.
   • Пример: Проверка, что оператор может зарегистрировать обращение, изменить его статус, прикрепить файл; что клиент может просмотреть историю своих обращений.
4. Нагрузочное (Performance/Load) тестирование: Оценка производительности системы под определенной нагрузкой (количество одновременных пользователей, запросов). Цель — определить, как система ведет себя при пиковых нагрузках, выявить узкие места.
   • Пример: Имитация 100 одновременных операторов и 500 клиентов в личном кабинете, проверяя время отклика системы на типовые операции.
5. Приемочное (Acceptance) тестирование: Финальное тестирование, проводимое заказчиком или конечными пользователями для подтверждения, что система удовлетворяет их ожиданиям и готова к вводу в эксплуатацию.
   • Пример: Клиенты и операторы техподдержки проверяют систему в условиях, максимально приближенных к реальным.

Критерии качества программного обеспечения:
Качество ПО — это многогранное понятие, которое регулируется международным стандартом ISO/IEC 25010:2011 (System and software Quality Requirements and Evaluation — SQuaRE) и отечественным ГОСТ 28195-99 «Обеспечение качества программных средств». Эти стандарты выделяют следующие ключевые характеристики:

1. Функциональность: Способность ПО выполнять заявленные функции, удовлетворять явным и неявным потребностям.
   • Показатели: Полнота функций, корректность, адекватность, защищенность от несанкционированного доступа.
2. Производительность (Efficiency): Эффективность использования ресурсов (время, процессор, память) при выполнении функций.
   • Показатели: Время отклика, пропускная способность, загрузка ресурсов.
3. Системность (Compatibility): Способность ПО взаимодействовать с другими системами или компонентами.
   • Показатели: Совместимость с различными ОС, браузерами, интеграция с другими ИС.
4. Надежность (Reliability): Способность ПО работать без сбоев в заданных условиях в течение определенного периода времени.
   • Показатели: Отказоустойчивость (способность продолжать работу при сбоях), самовосстанавливаемость, безотказность, количество ошибок до/после отладки, наработка часов на отказ, интенсивность отказов, вероятность безотказного действия.
   • Надежность рекомендуется характеризовать уровнем завершенности (отсутствия ошибок), устойчивостью к ошибкам и перезапускаемостью.
5. Защищенность (Security): Способность ПО защищать информацию и ресурсы от несанк��ионированного доступа.
   • Показатели: Конфиденциальность, целостность, доступность, неотказуемость, подлинность.
6. Удобство использования (Usability): Легкость освоения, понятность и привлекательность для пользователей.
   • Показатели: Понятность, обучаемость, эргономичность, удовлетворенность пользователя.
7. Модифицируемость (Maintainability): Легкость внесения изменений, исправления ошибок, адаптации к новым требованиям.
   • Показатели: Анализируемость, изменяемость, стабильность, тестируемость.
8. Адаптивность (Portability/Cross-platform): Способность ПО функционировать в различных средах (операционные системы, аппаратные платформы) без существенных изменений.
   • Показатели: Устанавливаемость, заменяемость.

Соответствие стандартам:
Разрабатываемое ПО должно соответствовать не только функциональным требованиям, но и высоким стандартам качества. В дипломной работе необходимо описать, как система будет соответствовать вышеуказанным критериям, ссылаясь на международные стандарты (ISO/IEC 25010:2011) и отечественные ГОСТы (ГОСТ 28195-99). Это может включать использование статических анализаторов кода, написание юнит-тестов, проведение нагрузочного тестирования и документирование результатов. Например, для обеспечения надежности будет предусмотрен механизм логирования ошибок и автоматического перезапуска сервисов. Для защищенности — применение современных методов шифрования и аутентификации.

Развертывание (Deploy) и сопровождение системы

После успешной реализации и тестирования информационно-справочной системы наступает этап, когда она должна быть передана в эксплуатацию – то есть развернута (задеплоена) и затем сопровождаться. Эти процессы являются критически важными для обеспечения работоспособности, доступности и долгосрочной эффективности системы.

Процесс развертывания веб-приложения (Deploy):
Деплой (от англ. deployment) – это процесс размещения готового программного продукта (веб-сайта, приложения, сервиса) в операционной среде, где он становится доступным конечным пользователям. Этот процесс состоит из нескольких ключевых этапов:

1. Отправка кода: Исходный код приложения (чаще всего из репозитория Git) передается на сервер или в облачную среду.
2. Установка зависимостей: Установка всех необходимых библиотек, фреймворков и пакетов, от которых зависит приложение (например, npm install для Node.js или pip install -r requirements.txt для Python).
3. Сборка (Build): Для некоторых приложений (особенно с Frontend-фреймворками) требуется этап сборки, где исходный код компилируется или транспилируется в исполняемые файлы, оптимизируется для продакшн-среды (например, npm run build).
4. Конфигурация среды: Настройка переменных окружения, подключений к базе данных, файрволов, веб-серверов (Nginx, Apache).
5. Запуск: Запуск приложения на сервере, часто с использованием менеджеров процессов (например, PM2 для Node.js, Gunicorn/uWSGI для Python), которые обеспечивают его непрерывную работу и перезапуск в случае сбоев.

Способы развертывания:

• Виртуальные частные серверы (VPS): Наиболее распространенный подход, где разработчик имеет полный контроль над операционной системой и средой. Требует ручной настройки или использования скриптов автоматизации.
• Облачные платформы (PaaS — Platform as a Service): Такие как Heroku, Google App Engine, AWS Elastic Beanstalk, OpenShift. Они предоставляют готовую среду для развертывания, абстрагируя разработчика от управления инфраструктурой. Это значительно упрощает деплой и масштабирование.

Использование систем оркестрации контейнеров (Kubernetes, Docker Swarm, Nomad) или PaaS-решений (OpenShift):
Для сложных, высоконагруженных систем или систем, построенных на микросервисной архитектуре, ручное развертывание и управление могут быть крайне сложными. Здесь на помощь приходят системы оркестрации контейнеров.

• Docker: Позволяет упаковать приложение со всеми его зависимостями в легковесные, переносимые «контейнеры», гарантируя, что оно будет работать одинаково в любой среде.
• Kubernetes: Де-факто стандарт для оркестрации контейнеров. Это мощная платформа для автоматизации развертывания, масштабирования и управления контейнеризированными приложениями. Она обеспечивает высокую доступность, самовосстановление и балансировку нагрузки.
• Docker Swarm, Nomad, Apache Mesos: Альтернативные решения для оркестрации, предлагающие различные подходы к управлению кластерами контейнеров.
• OpenShift (PaaS на базе Kubernetes): Платформа как услуга, построенная на Kubernetes, предоставляющая дополнительные инструменты для разработчиков и операций, упрощающая CI/CD и управление жизненным циклом приложений.

Для нашей ИСС техподдержки, особенно если она будет развиваться и масштабироваться, применение контейнеризации с помощью Docker и последующая оркестрация с Kubernetes или использование OpenShift обеспечат максимальную гибкость, надежность и эффективность управления развертыванием.

Организация сопровождения информационной системы:
Внедрение информационной системы — это не конечная точка, а начало нового этапа — сопровождения. Этот этап является не менее важным, чем разработка, и включает:

1. Оперативное устранение проблем (Bug Fixing): Выявление и исправление ошибок, возникающих в процессе эксплуатации.
2. Мониторинг производительности: Постоянный контроль за работоспособностью системы, ее производительностью, использованием ресурсов, нагрузкой на серверы и базы данных. Используются системы мониторинга (Prometheus, Grafana, Zabbix).
3. Обеспечение защиты информации: Регулярное обновление системы безопасности, контроль доступа, аудит событий, предотвращение кибератак, установка патчей безопасности.
4. Добавление новых функций (Feature Development): Реализация новых требований пользователей или бизнеса, модернизация существующего функционала.
5. Управление изменениями: Контролируемый процесс внесения всех изменений в систему, включая тестирование, документацию и информирование пользователей.

Связь сопровождения ИС со второй и третьей линиями технической поддержки:
Структура линий техподдержки идеально ложится на процессы сопровождения:

• Вторая линия поддержки (L2): Занимается оперативными исправлениями, диагностикой сложных проблем, мониторингом и решением инцидентов, которые не могут быть устранены первой линией. Специалисты L2 обладают глубокими знаниями системы и могут взаимодействовать с базой данных и конфигурационными файлами.
• Третья линия поддержки (L3): Состоит из высококвалифицированных разработчиков и системных инженеров, которые отвечают за исправление программных ошибок (багфиксинг), разработку нового функционала (добавление новых функций), оптимизацию производительности и глубокий анализ сложных системных сбоев. Они взаимодействуют с исходным кодом системы.

Таким образом, сопровождение ИСС – это непрерывный процесс, требующий тесного взаимодействия между командами разработки и эксплуатации, а также использования эффективных инструментов для мониторинга и управления изменениями.

Глава 4. Информационная Безопасность, Отказоустойчивость и Правовые Аспекты

Краткая аннотация

Эта глава посвящена критически важным аспектам функционирования любой современной информационной системы: обеспечению ее стабильности, безопасности и конфиденциальности данных. Мы рассмотрим механизмы отказоустойчивости, методы защиты информации, а также углубимся в актуальную нормативно-правовую базу Российской Федерации, включая новейшие регуляторные инициативы в сфере искусственного интеллекта. Цель — гарантировать, что разработанная ИСС будет не только функциональной, но и устойчивой к сбоям, защищенной от угроз и полностью соответствующей законодательным требованиям.

Обеспечение отказоустойчивости информационной системы

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

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

Ключевой аспект построения отказоустойчивой системы — избыточность. Это означает наличие резервных компонентов, которые могут взять на себя нагрузку в случае выхода из строя основного элемента. Избыточность может быть реализована на разных уровнях:

• Резервирование аппаратного обеспечения: Использование нескольких серверов (вместо одного), дублирование сетевых карт, блоков питания, жестких дисков (RAID).
• Резервирование каналов связи: Наличие нескольких интернет-провайдеров или различных физических линий связи.
• Резервирование данных: Регулярное создание резервных копий (бэкапов) и их хранение на разных носителях/локациях, репликация баз данных.
• Дублирование программных компонентов: Запуск нескольких экземпляров приложения или его сервисов, что позволяет одному экземпляру принять нагрузку, если другой выйдет из строя.

Существуют два основных подхода к построению отказоустойчивой системы:

1. Нормальное функционирование (Active-Active): В этом подходе все компоненты системы работают одновременно и обрабатывают запросы. В случае сбоя одного из них, нагрузка автоматически перераспределяется между оставшимися, и производительность системы остается на прежнем уровне (или почти на прежнем).
   • Пример: Несколько веб-серверов, работающих за балансировщиком нагрузки, или кластер баз данных с репликацией и автоматическим переключением на резервный узел.
2. Плавный спад производительности (Active-Passive / Graceful Degradation): При этом подходе один или несколько компонентов находятся в «горячем» или «холодном» резерве и активируются только в случае сбоя основного. Это может привести к временному снижению производительности или частичной потере функционала до полного восстановления. Влияние неполадки пропорционально ее масштабу.
   • Пример: Резервный сервер, который запускается вручную или автоматически при выходе из строя основного, или автоматическое переключение на упрощенный режим работы при высокой нагрузке.

Применение принципов отказоустойчивости для ИСС техподдержки телефонной сети включает:

• Резервирование каналов связи: Обеспечение нескольких каналов для входящих звонков и интернет-соединения для веб-приложения.
• Резервирование серверов приложений: Развертывание ИСС на нескольких веб-серверах за балансировщиком нагрузки. В случае отказа одного сервера, запросы будут автоматически перенаправлены на работающие.
• Резервирование баз данных: Настройка кластера базы данных (например, PostgreSQL) с репликацией (Master-Slave или Master-Master) и механизмом автоматического failover (переключения на резервный узел) в случае сбоя основного сервера БД.
• Резервирование хранилища файлов: Дублирование места хранения прикрепленных файлов и документов (например, в объектных хранилищах с высокой степенью избыточности).
• Мониторинг и оповещение: Внедрение систем мониторинга (Zabbix, Prometheus), которые отслеживают состояние всех компонентов системы и оперативно оповещают администраторов о любых отклонениях или сбоях.

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

Информационная безопасность и защита персональных данных

В современном цифровом мире, где данные являются новой нефтью, информационная безопасность (ИБ) и защита персональных данных (ПДн) приобретают первостепенное значение, особенно для систем, обрабатывающих конфиденциальную информацию клиентов, таких как ИСС технической поддержки. Нарушение ИБ может привести не только к финансовым потерям, но и к серьезному ущербу репутации компании и юридиче��ким последствиям.

Анализ потенциальных угроз и уязвимостей, специфичных для веб-ориентированных информационных систем:
Веб-приложения подвержены широкому спектру угроз, среди которых наиболее распространенными являются:

• SQL-инъекции: Атаки, при которых злоумышленник внедряет вредоносный SQL-код в поля ввода, заставляя базу данных выполнять несанкционированные операции (например, получать, изменять или удалять данные).
• Межсайтовый скриптинг (XSS — Cross-Site Scripting): Атаки, позволяющие злоумышленнику внедрять вредоносный клиентский скрипт в веб-страницы, просматриваемые другими пользователями. Это может привести к краже сессионных куки, обходу контроля доступа.
• Межсайтовая подделка запросов (CSRF — Cross-Site Request Forgery): Атаки, при которых пользователь вынужден выполнить нежелательные действия в веб-приложении, в котором он уже аутентифицирован.
• DDoS-атаки (Distributed Denial of Service): Атаки, направленные на исчерпание ресурсов сервера или канала связи, делая сервис недоступным для легитимных пользователей.
• Недостатки аутентификации и авторизации: Слабые пароли, отсутствие многофакторной аутентификации, некорректная реализация прав доступа.
• Чувствительные данные без надлежащей защиты: Хранение незашифрованных персональных данных, паролей, финансовой информации.

Методы защиты информации:
Для противодействия этим угрозам необходимо применять комплексный подход к ИБ:

• Аутентификация и авторизация: Использование надежных механизмов аутентификации (сложные пароли, многофакторная аутентификация), строгая ролевая модель авторизации для разграничения прав доступа к функционалу и данным.
• Шифрование данных: Шифрование всех передаваемых данных (HTTPS с TLS/SSL) и хранимых конфиденциальных данных (например, паролей, персональных данных в БД) с использованием стойких криптографических алгоритмов (AES-256).
• Контроль доступа: Применение принципа наименьших привилегий, регулярный аудит прав доступа.
• Системы обнаружения/предотвращения вторжений (IDS/IPS): Мониторинг сетевого трафика и системных логов для выявления подозрительной активности и предотвращения атак.
• Межсетевые экраны (Firewalls): Фильтрация входящего и исходящего трафика для предотвращения несанкционированного доступа.
• Безопасная разработка (Secure Coding): Обучение разработчиков принципам безопасного кодирования, использование фреймворков, которые автоматически предотвращают многие уязвимости (например, защита от SQL-инъекций в ORM Django).
• Регулярное тестирование на проникновение (Penetration Testing) и сканирование уязвимостей.
• Резервное копирование и восстановление: Создание регулярных, шифрованных бэкапов данных и плана восстановления после сбоев.

Соответствие законодательству Российской Федерации:
В России регулирование ИБ и ПДн является строгим и постоянно развивается. ИСС техподдержки должна строго соответствовать следующим ключевым нормативно-правовым актам:

• Федеральный закон от 27 июля 2006 г. № 149-ФЗ «Об информации, информационных технологиях и о защите информации»: Определяет правовые основы регулирования отношений в сфере информации, информационных технологий и защиты информации.
• Федеральный закон от 27 июля 2006 г. № 152-ФЗ «О персональных данных»: Ключевой документ, определяющий требования к обработке персональных данных российских граждан, устанавливающий принципы обработки, права субъектов ПДн и обязанности операторов. Обязывает обеспечивать конфиденциальность и безопасность ПДн.
• Приказ ФСТЭК России № 21 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»: Детализирует конкретные организационные и технические меры, которые операторы ИСПДн (информационных систем персональных данных) должны применять в зависимости от уровня защищенности ПДн.
• Постановление Правительства РФ № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»: Определяет требования к защите ПДн при их обработке в ИСПДн, классифицирует ИСПДн по уровням защищенности.

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

Правовое регулирование и этические аспекты применения ИИ в системах поддержки (для будущей модернизации)

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

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

• Проект концепции комплексного регулирования ИИ: В августе 2025 года Минцифры РФ предложило проект концепции, основанной на человекоориентированном подходе, с целью создания благоприятных условий для безопасного развития технологий ИИ в России.
• Законопроект «О регулировании систем искусственного интеллекта в России»: Активно разрабатывается. Он предполагает классификацию систем ИИ по уровню потенциального риска, с запретом на разработку и эксплуатацию систем с неприемлемым уровнем риска (создающих угрозу безопасности личности, общества и государства).
• Федеральный закон № 258-ФЗ от 31 июля 2020 года «Об экспериментальных правовых режимах в сфере цифровых инноваций»: Позволяет создавать «регуляторные песочницы» для апробации новых технологий, в том числе ИИ. На данный момент действует 14 таких режимов, 13 из которых связаны с беспилотным транспортом и здравоохранением.
• Ответственность за вред от ИИ: С 9 июля 2024 года в России введена ответственность за причинение вреда при использовании решений с искусственным интеллектом, включая страхование рисков. Это обеспечивает дополнительную защиту для граждан и юридических лиц и является важным шагом в формировании правового поля.
• Ужесточение ответственности за кибермошенничество с ИИ: В августе 2025 года Минцифры РФ предложило новые штрафы и ужесточение ответственности, предусматривающие до шести лет тюрьмы или штраф до 500 тыс. рублей за применение нейросетей при совершении киберпреступлений.

Юридическое определение ИИ:
Рабочая группа Госдумы по разработке законопроекта о регулировании ИИ предложила следующее юридическое определение:
«любая система данных, программное обеспечение или аппаратное средство, обладающее способностью обрабатывать данные и информацию способом, напоминающим разумное поведение, с использованием методов машинного обучения или статистических методов для генерации контента, формирования прогнозов, рекомендаций или решений, способных оказывать влияние на реальную и виртуальную среду». Это определение охватывает широкий спектр технологий, от простых алгоритмов машинного обучения до сложных нейронных сетей.

Этические вопросы сбора, обработки и использования данных:
Внедрение ИИ-компонентов в ИСС техподдержки поднимает ряд серьезных этических вопросов:

• Прозрачность и объяснимость: Насколько прозрачны и объяснимы решения, принимаемые ИИ? Пользователи и операторы должны понимать, почему ИИ предложил то или иное решение или рекомендацию.
• «Смещенность» (Bias): Обучение ИИ на предвзятых данных может привести к несправедливым или дискриминационным результатам. Важно разрабатывать и тестировать ИИ-модели на предмет «смещенности» и обеспечивать робастность нейронных сетей.
• Конфиденциальность и безопасность данных: ИИ-системы часто требуют доступа к большим объемам данных, включая персональные. Необходимо гарантировать их конфиденциальность и защиту от несанкционированного доступа.
• Автономия и контроль человека: Какова степень автономии ИИ в принятии решений? Необходимо сохранить человеческий контроль над критически важными процессами и решениями.
• Ответственность: Кто несет ответственность в случае ошибки или вреда, причиненного ИИ? Новые законы, вводящие ответственность за вред от ИИ, начинают решать эту проблему.
• Использование ИИ для манипуляций или обмана: Предложения Минцифры РФ о штрафах за кибермошенничество с ИИ подчеркивают актуальность этого вопроса.

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

Глава 5. Экономическое Обоснование и Социальный Эффект Проекта

Краткая аннотация

Эта глава посвящена анализу экономической целесообразности внедрения разработанной информационно-справочной системы и оценке ее широкого социального эффекта. Мы рассчитаем ключевые финансовые показатели, такие как возврат инвестиций, и проанализируем, как система повлияет на удовлетворенность клиентов, эффективность работы персонала и имидж компании. Цель — показать, что инвестиции в ИСС не только окупятся, но и принесут значительные долгосрочные выгоды.

Расчет экономических показателей проекта

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

Методика оценки затрат на разработку и внедрение информационной системы:
Затраты на проект можно разделить на две основные категории:

1. Единовременные (капитальные) расходы (CAPEX):
   • Разработка ПО: Затраты на заработную плату команды разработчиков (аналитиков, проектировщиков, программистов, тестировщиков, дизайнеров UI/UX) за период разработки.
   • Приобретение оборудования: Серверы, сетевое оборудование, рабочие станции для персонала, лицензии на ПО (ОС, СУБД, средства разработки, если они платные).
   • Лицензии на стороннее ПО/сервисы: Если используются коммерческие базы данных, облачные сервисы, специализированные инструменты.
   • Обучение персонала: Затраты на проведение тренингов для операторов и администраторов системы.
   • Внедрение и настройка: Расходы на инсталляцию, конфигурацию, интеграцию с существующими системами.
   • Создание начальной базы знаний: Затраты на формирование контента для БЗ.
2. Текущие (операционные) расходы (OPEX):
   • Сопровождение и поддержка ПО: Заработная плата специалистов по сопровождению, абонентская плата за поддержку от вендора.
   • Обслуживание оборудования: Электроэнергия, охлаждение, ремонт.
   • Лицензии и подписки: Ежегодные платежи за ПО, облачные сервисы.
   • Модернизация и развитие: Затраты на добавление нового функционала, обновления.
   • Сетевая инфраструктура: Оплата каналов связи, хостинга.

Расчет возврата инвестиций (ROI), срока окупаемости и других финансовых показателей:

1. Расчет ROI (Return on Investment):
ROI показывает процентное соотношение прибыли от инвестиций к их стоимости.

Формула:
ROI = (Доход от проекта — Затраты на проект) / Затраты на проект × 100%

Для расчета ROI необходимо определить не только затраты, но и доход (экономию), который принесет ИСС.
Пример расчета ожидаемой экономии и дохода:

• Сокращение времени обработки обращений: Допустим, среднее время обработки обращения сократится с 15 до 10 минут. При 10000 обращений в месяц и средней зарплате оператора X рублей в час, можно рассчитать экономию на трудозатратах.
  • Экономия времени на 1 обращение = 5 минут = 5/60 часа.
  • Общая экономия времени в месяц = 10000 обр. × 5/60 ч/обр. = 833.33 часа.
  • Экономия в денежном выражении = 833.33 ч × X руб./ч.
• Сокращение входящих звонков благодаря базе знаний: Источники указывают, что база знаний в Help Desk системе может сократить входящие звонки в поддержку на 5%. Если в месяц поступает 20000 звонков, то 1000 звонков будут решаться клиентами самостоятельно. Это снижает нагрузку на операторов.
• Повышение конверсии и дохода от онлайн-чата: Онлайн-чат может увеличить доход на 48% за час разговора, а общий коэффициент конверсии — на 40%. Если ИСС включает онлайн-чат, можно спрогнозировать прирост дохода.
• Уменьшение текучки кадров: Улучшение условий труда операторов, автоматизация рутины, снижение стресса.
• Улучшение имиджа компании: Привлечение новых клиентов благодаря более качественному сервису.

2. Расчет срока окупаемости (Payback Period):
Срок окупаемости — это время, за которое инвестиции в проект окупятся за счет получаемой прибыли (экономии).

Формула:
Срок окупаемости = Единовременные затраты / (Годовая экономия — Годовые текущие затраты)

3. Расчет NPV (Net Present Value — Чистая приведенная стоимость) и IRR (Internal Rate of Return — Внутренняя норма доходности):
Эти показатели используются для оценки долгосрочной инвестиционной привлекательности проекта, учитывая дисконтирование будущих денежных потоков. Для дипломной работы достаточно будет базового расчета ROI и срока окупаемости.

Пример структуры расчета:

Таблица 5.1. Пример структуры экономических расчетов

Показатель	Значение / Расчет
Единовременные затраты (CAPEX):
— Заработная плата команды	1 500 000 руб. (6 чел. х 250 000 руб./мес. х 1 мес.)
— Оборудование и ПО	300 000 руб. (сервер, лицензии СУБД)
— Обучение персонала	100 000 руб.
Итого CAPEX:	1 900 000 руб.
Годовые текущие затраты (OPEX):
— Сопровождение ИС	600 000 руб. (2 чел. х 25000 руб./мес. х 12 мес.) — Гипотетически
— Амортизация оборудования	60 000 руб. (300 000 руб. / 5 лет)
— Хостинг/облако	120 000 руб. (10 000 руб./мес. х 12 мес.)
Итого OPEX (год):	780 000 руб.
Ожидаемая годовая экономия/доход:
— Сокращение времени обработки	1 000 000 руб. (расчет по 833.33 ч/мес. и 1000 руб./ч)
— Сокращение входящих звонков	200 000 руб. (экономия на ФОТ операторов)
— Повышение конверсии	300 000 руб. (от онлайн-чата)
Итого годовая экономия/доход:	1 500 000 руб.
Расчет ROI:	(1 500 000 — 780 000) / 1 900 000 = 0.379 = 37.9%
Срок окупаемости:	1 900 000 / (1 500 000 — 780 000) = 1 900 000 / 720 000 ≈ 2.64 года (2 года 8 месяцев)

Этот расчет показывает, что даже при консервативных оценках, инвестиции в ИСС техподдержки являются выгодными и окупаются в разумные сроки.

Оценка социальной эффективности и значимости

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

1. Повышение удовлетворенности клиентов за счет улучшения качества и скорости обслуживания:
   • Оперативность: Благодаря автоматизации маршрутизации, централизованной базе знаний и личному кабинету, клиенты получают более быстрые ответы и решения своих проблем.
   • Единообразие информации: Клиенты получают согласованную информацию, независимо от того, с каким оператором или каналом связи они взаимодействуют, что исключает путаницу и повторные обращения.
   • Прозрачность: Возможность отслеживать статус своего обращения в личном кабинете повышает доверие и снимает тревогу.
   • Доступность 24/7: Публичная база знаний и чат-боты (в перспективе) позволяют клиентам самостоятельно находить ответы на вопросы в любое время.
   • Все это способствует росту лояльности, снижению оттока клиентов и формированию позитивного клиентского опыта.
2. Оптимизация бизнес-процессов, снижение нагрузки на персонал техподдержки, улучшение имиджа компании и привлечение новых клиентов:
   • Для компании: Внедрение ИС помогает упорядочить ключевые бизнес-процессы, выявить проблемные места и значительно повысить эффективность работы службы поддержки за счет автоматизации рутинных задач. Это позволяет сотрудникам сосредоточиться на более сложных запросах, требующих человеческого интеллекта и эмпатии.
   • Для персонала: Снижение рутинной нагрузки, наличие структурированной информации и автоматизированных инструментов уменьшает стресс и выгорание операторов, повышает их производительность и профессионализм.
   • Имидж и конкурентоспособность: Качественное обслуживание клиентов является одним из основных факторов при выборе поставщика услуг. Внедрение современной ИСС улучшает имидж компании, делает ее более привлекательной для потенциальных клиентов и усиливает ее позиции на рынке.
3. Влияние внедрения системы на условия труда сотрудников, их мотивацию и возможности профессионального роста:
   • Комфорт работы: Централизованная система с удобным интерфейсом значительно упрощает работу операторов, предоставляя им все необходимые инструменты и информацию в одном месте.
   • Мотивация: Уменьшение монотонных задач и возможность сосредоточиться на решении более сложных и интересных проблем повышает мотивацию сотрудников.
   • Профессиональный рост: ИСС может включать модули для обучения, оценки знаний и компетенций, что способствует развитию персонала и повышению их квалификации. Операторы становятся не просто «приемщиками звонков», а квалифицированными специалистами, способными решать широкий круг задач.
   • Снижение текучки кадров: Улучшенные условия труда и возможности для развития делают компанию более привлекательной для удержания талантливых специалистов.
4. Перспективы использования технологий информационного моделирования (ТИМ) для долгосрочного развития, управления и эффективной эксплуатации ИТ-инфраструктуры:
   • Хотя ИСС техподдержки напрямую не является ТИМ (которые чаще применяются в строительстве и инженерии для 3D-моделирования), принципы информационного моделирования могут быть применены к управлению ИТ-инфраструктурой, частью которой является ИСС.
   • ТИМ помогают избежать коллизий на этапе проектирования (в данном случае, ИТ-архитектуры), минимизировать риски и оперативно принимать решения, обеспечивая слаженное строительство и эффективную работу ИТ-систем.
   • Использование похожих принципов для «моделирования» всей ИТ-инфраструктуры, включая сервисы, сервера, сетевые соединения и их зависимости, позволяет лучше управлять сложными системами, прогнозировать проблемы и планировать модернизацию.
   • Это создает основу для будущего развития, позволяя легко интегрировать новые модули (например, ИИ-компоненты), масштабировать систему и адаптировать ее к меняющимся бизнес-потребностям.

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

Глава 6. Требования к Оформлению Дипломной Работы и Защите

Краткая аннотация

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

Общие требования и структура дипломной работы

Дипломная работа (выпускная квалификационная работа бакалавра/магистра) является самостоятельным научным исследованием, демонстрирующим уровень подготовки студента, его способность применять теоретические знания и практические навыки для решения актуальных профессиональных задач. Она должна соответствовать требованиям образовательного стандарта по соответствующей специальности (например, «Информационные системы и технологии», «Программная инженерия») и методическим рекомендациям конкретного высшего учебного заведения.

Основные требования к дипломной работе:

• Актуальность: Тема должна быть актуальной, отражать современные тенденции в IT-сфере и иметь практическую значимость.
• Научность: Работа должна содержать элементы научного исследования, обоснованные выводы и рекомендации.
• Самостоятельность: Работа должна быть выполнена студентом самостоятельно, демонстрируя его индивидуальные компетенции.
• Целостность: Все части работы должны быть логически связаны и направлены на достижение поставленных целей и задач.
• Практическая значимость: Результаты работы должны иметь потенциал для практического применения.

Обязательные структурные элементы дипломной работы (проекта):

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

Строгое следование этой структуре и требованиям вуза является залогом успешной подготовки и защиты дипломной работы.

Правила оформления текстовой части

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

• ГОСТ 7.32-2017 «Отчет о научно-исследовательской работе. Структура и правила оформления»: Является основным стандартом, регулирующим общую структуру, правила оформления заголовков, текста, рисунков, таблиц, ссылок и приложений.
• ГОСТ Р 7.0.100-2018 «Библиографическая запись. Библиографическое описание»: Определяет правила составления списка использованных источников.
• ГОСТ 2.105-2019 «Общие требования к текстовым документам»: Устанавливает общие требования к текстовым документам, включая правила оформления текста, нумерации, заголовков и т.д.

Конкретные правила оформления:

• Нумерация страниц: Страницы дипломной работы нумеруются арабскими цифрами сквозной нумерацией по всему объему работы. Номер проставляется внизу листа по центру. Важно: На титульном листе, аннотации, задании на выполнение ВКР и оглавлении номер страницы не ставится, но эти страницы включаются в общую нумерацию.
• Размеры полей страницы:
  • Левое поле: 3 см (для подшивки).
  • Правое поле: 1.5 см.
  • Верхнее поле: 2 см.
  • Нижнее поле: 2 см.
• Шрифт основного текста: Times New Roman, размер 14 пт.
• Межстрочный интервал: Полуторный.
• Абзацный отступ: Должен быть одинаковым по всей работе и составлять 1.25 см.
• Заголовки разделов и подразделов:
  • Разделы и подразделы должны иметь заголовки, четко и кратко отражающие их содержание.
  • Заголовки печатаются без точки в конце и без подчеркивания.
  • Заголовки глав (H1) – заглавными буквами, выравниваются по центру.
  • Заголовки подразделов (H2, H3) – строчными буквами (кроме первой), выравниваются по левому краю.
  • Между заголовком и текстом, а также между заголовками разных уровней должны быть пропущены одна или две строки.
• Нумерация параграфов (подразделов) в пределах каждой главы: Номер параграфа состоит из номера главы и номера параграфа, разделенных точкой (например, 1.1; 1.2; 1.3, а затем 2.1; 2.2 и т.д.).
• Ссылки на использованные источники: Указываются арабскими цифрами в квадратных скобках [1] после цитаты или заимствованных данных, в соответствии с порядком появления источника в списке литературы. Например: «Актуальность темы подтверждается статистическими данными [5]«.

Соблюдение этих правил обеспечит профессиональный вид дипломной работы и соответствие академическим стандартам.

Оформление графического материала и приложений

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

Требования к оформлению таблиц:

• Нумерация: Таблицы нумеруются арабскими цифрами сквозной нумерацией по всей работе или в пределах каждой главы. Например, «Таблица 1.1 – Название таблицы» (для первой таблицы первой главы) или «Таблица 5 – Название таблицы» (сквозная нумерация).
• Заголовок: Каждая таблица должна иметь содержательный заголовок, который размещается над таблицей слева, после слова «Таблица» и ее номера.
• Расположение: Таблицы располагаются непосредственно после ссылки на них в тексте.
• Шрифт: В таблицах допускается использование шрифта меньшего размера (например, Times New Roman, 12 пт) и одинарного межстрочного интервала.
• Повторение заголовков: При переносе таблицы на следующую страницу необходимо повторить заголовки столбцов или пронумеровать их и повторить номера.
• Примечания: Если необходимо, под таблицей размещаются примечания.

Требования к оформлению рисунков, диаграмм, схем и графиков:

• Нумерация: Рисунки (схемы, диаграммы, графики) нумеруются арабскими цифрами аналогично таблицам: сквозная нумерация по всей работе или в пределах каждой главы (например, «Рисунок 2.1 – Название рисунка»).
• Заголовок: Каждый рисунок должен иметь содержательный заголовок, который размещается под рисунком по центру, после слова «Рисунок» и его номера.
• Расположение: Рисунки располагаются непосредственно после ссылки на них в тексте.
• Ссылка: На все рисунки и таблицы должны быть ссылки в тексте работы. Например: «как показано на Рисунке 2.3».
• Качество: Все графические материалы должны быть четкими, легко читаемыми, с достаточным разрешением.

Содержание приложений:

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

Типовое содержание приложений для дипломной работы по разработке ИСС:

• Листинги кода: Фрагменты или полный код наиболее значимых модулей, функций, классов, скриптов базы данных.
• Техническое задание (ТЗ): Полный текст ТЗ на разработку системы.
• Акты тестирования: Документы, подтверждающие проведение различных видов тестирования (модульного, интеграционного, функционального) и их результаты.
• Пользовательские инструкции: Фрагменты или полные инструкции для операторов и конечных пользователей системы.
• Скриншоты интерфейса: Изображения ключевых экранов разработанной системы, демонстрирующие ее функционал и пользовательский интерфейс.
• Диаграммы и схемы: Дополнительные UML-диаграммы, ER-диаграммы, архитектурные схемы, диаграммы бизнес-процессов, если они не были включены в основную часть работы.
• Фактические данные: Исходные данные, использованные для анализа, моделирования или тестирования.
• Нормативные правовые документы: Выдержки из законов, стандартов, регламентов, если они имеют прямое отношение к проекту.

Каждое приложение должно начинаться с новой страницы, иметь заголовок «ПРИЛОЖЕНИЕ А«, «ПРИЛОЖЕНИЕ Б» и т.д., а также содержательный заголовок. На все приложения должны быть ссылки в тексте основной части работы.

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

Заключение

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

В ходе работы были достигнуты следующие ключевые результаты:

• Анализ предметной области и формирование требований: Проведен детальный анализ текущего состояния службы технической поддержки, выявлены ее узкие места. На основе этого анализа, а также с учетом принципов ITIL 4 и стандартов ГОСТ 34 серии, были сформулированы исчерпывающие функциональные и нефункциональные требования к будущей ИСС.
• Проектирование архитектуры и информационной модели: С использованием методов системного анализа, таких как UML-диаграммы (прецедентов, классов, последовательности) и ER-моделирование, была разработана логическая и физическая архитектура системы. Обоснован выбор многослойной архитектуры и паттерна MVC, а также рассмотрены принципы Чистой и Событийно-ориентированной архитектур для обеспечения масштабируемости. Выбрана реляционная СУБД PostgreSQL и произведена нормализация данных до 3НФ.
• Обоснование технологий реализации: Выбран оптимальный стек технологий, включающий Frontend-фреймворк React (с Next.js) и Backend-фреймворки (Django/Express.js), обеспечивающий высокую производительность, масштабируемость и соответствие современным стандартам веб-разработки.
• План реализации, тестирования и внедрения: Детализированы этапы жизненного цикла разработки ПО. Описаны виды тестирования, критерии качества программного обеспечения (согласно ISO/IEC 25010:2011 и ГОСТ 28195-99), а также стратегии развертывания (CI/CD, контейнеризация с Kubernetes) и сопровождения системы.
• Обеспечение информационной безопасности и отказоустойчивости: Разработаны меры по обеспечению отказоустойчивости системы (резервирование, дублирование) и инфо��мационной безопасности (шифрование, аутентификация, авторизация, защита от веб-уязвимостей) в соответствии с ФЗ № 149-ФЗ, ФЗ № 152-ФЗ, Приказом ФСТЭК № 21 и Постановлением Правительства РФ № 1119.
• Анализ правового регулирования ИИ: В контексте будущей модернизации рассмотрены актуальные российские нормативно-правовые акты (2024-2025 гг.) по регулированию искусственного интеллекта, его этическим аспектам и ответственности за вред, что демонстрирует способность системы к адаптации к будущим технологическим вызовам.
• Экономическое обоснование и социальный эффект: Произведен расчет основных экономических показателей, таких как ROI и срок окупаемости, демонстрирующий финансовую целесообразность проекта. Оценена социальная эффективность, включая повышение удовлетворенности клиентов, оптимизацию работы персонала и улучшение имиджа компании.
• Требования к оформлению: Детально изложены требования к структуре и оформлению дипломной работы в соответствии с ГОСТ 7.32-2017 и другими релевантными стандартами.

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

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

Перспективы дальнейшего развития и модернизации системы включают:

• Внедрение ИИ-компонентов: Разработка интеллектуального чат-бота для автоматического ответа на типовые вопросы, использование машинного обучения для интеллектуальной маршрутизации обращений и прогнозирования проблем.
• Расширение функционала: Добавление модулей для проактивного мониторинга оборудования клиентов, интеграция с CRM-системами для персонализированного обслуживания, внедрение аналитики больших данных для выявления скрытых тенденций.
• Мобильное приложение: Разработка мобильного приложения для клиентов, предоставляющего доступ к личному кабинету, базе знаний и возможность создания обращений.

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

Список использованных источников
Приложения

Список использованной литературы

1. Емельянова Н.З., Партыка Т.Л., Попов И.И. Основы построения автоматизированных информационных систем. М.: Форум, Инфра-М, 2007.
2. Муссиано Ч., Кеннеди Б. HTML и XHTML. Подробное руководство, 6-е издание.
3. Ульман Д.Д., Уидом Д. Основы реляционных баз данных. М.: Лори, 2006.
4. Харрингтон Д.Л. Проектирование реляционных баз данных. Лори, 2006.
5. Хендерсон К. Профессиональное руководство по SQL Server. Структура и реализация (+ CD-ROM). М.: Вильямс, 2006.
6. Пушкарев П. Web script.ru. Управление сайтом. URL: http://webscript.ru/stories/02/01/03/3584690 (дата обращения: 27.10.2025).
7. Ачагу Р.М. Характеристика программного продукта. URL: http://synopsis.kubsu.ru/informatic/operator/lecture/theme3_1_1.htm (дата обращения: 27.10.2025).
8. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. М.: Финансы и статистика, 2002.
9. Министерство здравоохранения Российской Федерации. Гигиенические требования к вычислительной технике, условиям и организации работы. М., 2002.
10. Функциональные и нефункциональные требования (с примерами) – Visure Solutions. URL: https://www.visuresolutions.com/ru/requirements-management/functional-and-non-functional-requirements-with-examples (дата обращения: 27.10.2025).
11. Самые важные архитектурные шаблоны, которые нужно знать – Habr. URL: https://habr.com/ru/companies/globalsign/articles/523170/ (дата обращения: 27.10.2025).
12. 6 лучших веб-фреймворков Go для масштабируемых приложений – OpenReplay Blog. URL: https://blog.openreplay.com/best-go-web-frameworks-for-scalable-applications/ (дата обращения: 27.10.2025).
13. Проектирование реляционных баз данных: основные принципы – Habr. URL: https://habr.com/ru/companies/ruvds/articles/731382/ (дата обращения: 27.10.2025).
14. Frontend и Backend-разработка: в чем разница – IAMPM. URL: https://iampm.club/blog/frontend-i-backend-razrabotka-v-chem-raznitsa/ (дата обращения: 27.10.2025).
15. Чем определяется надёжность программного обеспечения. URL: https://ntc-foton.ru/articles/chem-opredelyaetsya-nadezhnost-programmnogo-obespecheniya/ (дата обращения: 27.10.2025).
16. Frontend или backend-разработка: что это и как сделать правильный выбор. URL: https://synergy.ru/stories/frontend-ili-backend-razrabotka-chto-eto-i-kak-sdelat-pravilnyiy-vybor (дата обращения: 27.10.2025).
17. Деплой веб-приложений: что это и способы развёртывания – МТС Exolve. URL: https://exolve.ru/blog/deploy-veb-prilozhenij-chto-eto-i-sposoby-razvertyvaniya/ (дата обращения: 27.10.2025).
18. Frontend VS Backend-разработка: какой путь выбрать? – Lemon.School. URL: https://lemon.school/ru/blog/frontend-vs-backend-development/ (дата обращения: 27.10.2025).
19. Что такое информационно-справочная система? – Справочник технического переводчика. URL: https://spp.slovaronline.com/1392-INFORMATSIONNO-SPRAVOCHNAYA-SISTEMA (дата обращения: 27.10.2025).
20. Внедрение и сопровождение информационных систем – Dynamicsun. URL: https://dynamicsun.ru/uslugi/vnedrenie-i-soprovozhdenie-informacionnykh-sistem (дата обращения: 27.10.2025).
21. Критерии обеспечение качества программного обеспечения – Точка Качества. URL: https://tochkachestva.ru/articles/kriterii-obespechenie-kachestva-programmnogo-obespecheniya/ (дата обращения: 27.10.2025).
22. Внедрение и сопровождение информационных систем – ОТР 2000. URL: https://www.otr.ru/service/vnedrenie-i-soprovozhdenie-is/ (дата обращения: 27.10.2025).
23. Лучшие backend-фреймворки для веб-разработки в 2024 году – Timeweb Cloud. URL: https://timeweb.cloud/blog/luchshie-backend-frejmvorki-dlya-veb-razrababotki (дата обращения: 27.10.2025).
24. Информационно-справочные системы (ИСС). URL: https://studfile.net/preview/17215161/page:2/ (дата обращения: 27.10.2025).
25. Фреймворки для веб-разработки – сравнение Angular, React и Vue js. URL: https://skillbox.ru/media/code/freymvorki-dlya-veb-razrabotki-sravnenie-angular-react-i-vue-js/ (дата обращения: 27.10.2025).
26. Критерии оценки качества программного продукта при тестировании – ИПАП. URL: https://www.ipap.ru/info/articles/kriterii-otsenki-kachestva-programmnogo-produkta-pri-testirovanii/ (дата обращения: 27.10.2025).
27. 12 современных веб-фреймворков для создания мощных приложений и API. URL: https://vc.ru/u/2126757-aleksandra-s/1126601-12-sovremennyh-veb-freymvorkov-dlya-sozdaniya-moschnyh-prilozheniy-i-api (дата обращения: 27.10.2025).
28. Отдел разработки, внедрения и сопровождения информационных систем – ИжГТУ. URL: https://istu.ru/ob-universitete/initsiativy-i-proekty/otdel-razrabotki-vnedreniya-i-soprovozhdeniya-informatsionnykh-sistem (дата обращения: 27.10.2025).
29. Фреймворки в веб-разработке – Web Creator. URL: https://web-creator.ru/articles/freymvorki-v-veb-razrabotke (дата обращения: 27.10.2025).
30. Разработка и внедрение информационных систем – Инфоком-С. URL: https://infocom-s.ru/razrabotka-i-vnedrenie-informacionnyx-sistem/ (дата обращения: 27.10.2025).
31. Нормативно-правовая база в области защиты информации. URL: https://its.ege.edu.ru/informacionnaya-bezopasnost/normativno-pravovaya-baza-v-oblasti-zashhity-informacii/ (дата обращения: 27.10.2025).
32. Как повысить отказоустойчивость ИТ-оборудования – ITG BY — itglobal. URL: https://itglobal.com/ru-by/blog/kak-povysit-otkazoustojchivost-it-oborudovaniya/ (дата обращения: 27.10.2025).
33. Топ аналогов и конкурентов HelpDesk 2025 года – PickTech. URL: https://picktech.ru/top/helpdesk-sistemy/ (дата обращения: 27.10.2025).
34. Показатели качества и надежности программного обеспечения. URL: https://studfile.net/preview/5267860/page:14/ (дата обращения: 27.10.2025).
35. Реляционные базы данных: основные принципы, структура и характеристики – Yandex Cloud — Документация. URL: https://cloud.yandex.ru/docs/managed-postgresql/concepts/relational-database-basics (дата обращения: 27.10.2025).
36. Основы и отличия Frontend и Backend разработки – Эльбрус Буткемп. URL: https://elbrusboot.camp/blog/frontend-backend-fullstack/ (дата обращения: 27.10.2025).
37. Защита персональных данных. Часть 1. Законы и требования – Habr. URL: https://habr.com/ru/companies/otus/articles/737718/ (дата обращения: 27.10.2025).
38. Этапы внедрения информационной системы – Сайт Тюмбит-АСУ. URL: https://tyumbit-asu.ru/infocenter/novosti-i-sobytiya/etapy-vnedreniya-informacionnoj-sistemy/ (дата обращения: 27.10.2025).
39. Нормативные правовые акты по информационной безопасности – КонсультантПлюс. URL: https://www.consultant.ru/cons/cgi/online.cgi?req=doc&base=CJI&n=225796&dst=1000000001#07166162383839607 (дата обращения: 27.10.2025).
40. Frontend и Backend-разработка: что это, в чем разница — что выбрать, бэкэнд или фронтэнд – Яндекс Практикум. URL: https://practicum.yandex.ru/blog/frontend-i-backend-razrabotka/ (дата обращения: 27.10.2025).
41. Качество и надежность программных систем – Омск — ОмГТУ. URL: https://cyberleninka.ru/article/n/kachestvo-i-nadezhnost-programmnyh-sistem (дата обращения: 27.10.2025).
42. ТОП-10 Help Desk систем для поддержки клиентов (2025). URL: https://web-komandor.ru/top-10-help-desk-sistem/ (дата обращения: 27.10.2025).
43. Топ Help Desk систем — лучшие инструменты для поддержки клиентов – Kaiten. URL: https://kaiten.ru/blog/help-desk-sistemy/ (дата обращения: 27.10.2025).
44. Сервисы технической поддержки: ТОП 13 лучших систем в 2025 году – VC.ru. URL: https://vc.ru/u/1529555-help-desk-sistemy/1324734-servisy-tehnicheskoy-podderzhki-top-13-luchshih-sistem-v-2025-godu (дата обращения: 27.10.2025).
45. Реляционная база данных – что это, принципы и применение – DECO systems. URL: https://decosys.ru/relacionnaya-baza-dannyx/ (дата обращения: 27.10.2025).
46. ТОП-10 Лучших программ для службы поддержки в 2025 году – TrashExpert.ru. URL: https://trashexpert.ru/luchshie-programmy-dlya-sluzhby-podderzhki (дата обращения: 27.10.2025).
47. Deploy (деплой): что это и для чего — этапы и внедрение деплоя проекта, как начать деплоить – Яндекс Практикум. URL: https://practicum.yandex.ru/blog/deploy/ (дата обращения: 27.10.2025).
48. Реляционная база данных. Проектирование реляционных баз данных – Otus. URL: https://otus.ru/journal/relyatsionnaya-baza-dannyh-proektirovanie-relyatsionnyh-baz-dannyh/ (дата обращения: 27.10.2025).
49. Нормативные документы по ИБ. Часть 3. Обзор российского и международного законодательства в области защиты персональных данных – Security Vision. URL: https://securityvision.ru/blog/normativnyie-dokumentyi-po-ib-chast-3-obzor-rossijskogo-i-mezhdunarodnogo-zakonodatelstva-v-oblasti-zashhityi-personalnyix-dannyix/ (дата обращения: 27.10.2025).
50. Нормативные документы – Центр информационных технологий. URL: https://cit.tlt.ru/normativnye-dokumenty (дата обращения: 27.10.2025).
51. Проектирование реляционной базы данных – Высшая школа экономики. URL: https://www.hse.ru/data/2012/10/05/1251025555/ДомЗад_БД.pdf (дата обращения: 27.10.2025).
52. Гайд по деплою web-приложений для новичков. Часть 1. Shared-хостинг – Habr. URL: https://habr.com/ru/companies/ruvds/articles/740324/ (дата обращения: 27.10.2025).
53. Разработка веб-приложений: основные этапы – Skypro. URL: https://sky.pro/media/razrabotka-veb-prilozhenij/ (дата обращения: 27.10.2025).
54. Deploy как этап разработки программного обеспечения – GeekBrains. URL: https://gb.ru/blog/deploy/ (дата обращения: 27.10.2025).
55. «СберТех» и «Корус Консалтинг» обеспечат работу ИТ-систем крупных компаний. CNews, 2025. URL: https://www.cnews.ru/news/2025/10/24/sberteh_i_korus_konsalting_obespechat (дата обращения: 27.10.2025).
56. Архитектура ИТ решений. Часть 3. Информационная архитектура – Habr. URL: https://habr.com/ru/companies/ruvds/articles/803875/ (дата обращения: 27.10.2025).
57. Точка сборки будущего: как ТИМ кардинально преображают инженерное проектирование. ComNews, 2025. URL: https://www.comnews.ru/content/234795/2025-10-26/2025_43_tochka_sborki_buduschego_kak_tim_kardinalno_preobrazhayut_inzhenernoe_proektirovanie (дата обращения: 27.10.2025).
58. Как мир регулирует ИИ – Habr. URL: https://habr.com/ru/companies/raft/articles/803407/ (дата обращения: 27.10.2025).
59. Методические рекомендации по подготовке и защите дипломной работы (проекта) по специальности 09.02.07 Информационные системы и программирование. Квалификация – Инфоурок. URL: https://infourok.ru/metodicheskie-rekomendacii-po-podgotovke-i-zaschite-diplomnoy-raboti-proekta-po-specialnosti-informacionnie-sistemi-i-progra-6850069.html (дата обращения: 27.10.2025).
60. Основные требования к оформлению дипломной работы (Методические рекомендации). URL: https://gubkin.ru/upload/kafedra/diplom-bakalavr.pdf (дата обращения: 27.10.2025).
61. Правила оформления курсовых и дипломных работ и проектов, технические – Архангельский колледж телекоммуникаций. URL: https://aktt.ru/images/students/ucheba/pravila_oformleniya_kurs_dipl_rabot.pdf (дата обращения: 27.10.2025).
62. Оформление выпускной квалификационной работы бакалавра. Методические рекомендации – Ульяновский государственный технический университет. URL: https://www.ulstu.ru/media/attachments/methodical_materials/2023/11/02/%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B5_%D1%80%D0%B5%D0%BA%D0%BE%D0%BC%D0%B5%D0%BD%D0%B4%D0%B0%D1%86%D0%B8%D0%B8_%D0%92%D0%9A%D0%A0_2023.pdf (дата обращения: 27.10.2025).
63. Методические рекомендации по написанию и защите дипломных работ. URL: https://orel.ranepa.ru/upload/iblock/93d/metodicheskie_rekomendatsii_po_napisaniyu_i_zaschite_diplomnykh_rabot.pdf (дата обращения: 27.10.2025).