Проектирование и программная реализация высокомасштабируемой информационной системы и Web-сайта для предприятия HoReCa: Аналитический и технический отчет

В 2025 году цифровизация сферы общественного питания (HoReCa) перестала быть конкурентным преимуществом, превратившись в базовое требование выживания. По данным отраслевых исследований, рестораны, внедрившие системы онлайн-бронирования и автоматизированного управления заказами, демонстрируют рост коэффициента оборачиваемости посадочных мест в среднем на 18–25%. Это критически важный показатель, подчеркивающий, что успех современного предприятия HoReCa напрямую зависит от эффективности его информационной системы (ИС).

Настоящий аналитический и технический отчет представляет собой детальное исследование, проектирование и программную реализацию высокомасштабируемой информационной системы и сопутствующего Web-сайта для ресторана. Проект сочетает строгие академические методологии (RUP, НФБК) с прикладным анализом предметной области, обеспечивая студенту-разработчику готовую, обоснованную основу для выпускной квалификационной работы.

1. Теоретические основы и выбор методологии разработки ИС

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

Информационная система (ИС) определяется как взаимосвязанная совокупность средств, методов и персонала, используемых для хранения, обработки и выдачи информации в интересах достижения поставленной цели. Система управления базами данных (СУБД), в свою очередь, является комплексом программных средств, предназначенных для создания, ведения и использования баз данных. Жизненный цикл программного обеспечения (ЖЦ ПО) — это период времени, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации.

1.1. Жизненный цикл информационной системы и обзор методологий

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

Среди современных методологий разработки выделяются два основных полюса: «тяжелые» и «гибкие».

Критерий	Rational Unified Process (RUP)	Scrum (Agile)
Философия	Архитектурно-центрированный, управляемый рисками	Адаптивный, ориентированный на команду и частый фидбэк
Основная цель	Создание Корпоративных Информационных Систем (КИС) с четкой архитектурой	Быстрая поставка ценности, адаптация к меняющимся требованиям
Документация	Обширная, обязательные артефакты (Модель прецедентов, Модель архитектуры)	Минимальная, сосредоточена на User Stories и Backlog
Применимость для КИС	Высокая. Обеспечивает управляемость на ранних этапах.	Средняя. Требует высокой самоорганизации команды.

Детализированное описание фаз Rational Unified Process (RUP)

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

1. Начальная стадия (Inception): Главная цель — определить видение и границы проекта, провести анализ рисков и создать технико-экономическое обоснование (ТЭО). На этой фазе создается черновик Модели прецедентов.
2. Разработка (Elaboration): Установление устойчивой архитектуры. Происходит детализация функциональных требований и разработка базовой функциональности. Управление рисками является ключевым. На выходе — Модель архитектуры и исполняемый прототип.
3. Конструирование (Construction): Фаза итеративной разработки компонентов. Большая часть кодирования происходит здесь. Создается основной объем Выходного кода.
4. Внедрение (Transition): Развертывание системы, тестирование (приемочное), обучение пользователей и передача системы в эксплуатацию.

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

1.2. Роль CASE-средств и современных инструментов автоматизации

CASE-средства (Computer-Aided System Engineering) — это неотъемлемые инструменты для автоматизации процессов проектирования ИС. Их основная функция заключается в обеспечении технической целостности проекта, позволяя разработчику работать с моделями, а не напрямую с кодом на ранних стадиях.

Для структурного анализа бизнес-процессов (методология IDEF0) традиционно используется BPwin. Для логического и физического моделирования реляционных баз данных (ER-диаграммы) применяется ERwin. Эти инструменты позволяют генерировать код БД (DDL-скрипты) и обеспечивать соответствие модели и реализации.

Эволюция CASE-средств: Low/Less Code платформы

Современные платформы, такие как Jmix, выступают в роли эволюционировавших CASE-средств. Они не только автоматизируют разработку модели данных (как это делал ERwin), но и генерируют пользовательские экраны (UI), а также автоматизируют написание типового кода бизнес-процессов. Это минимизирует объем избыточного кода, что критически важно для сокращения сроков и стоимости разработки КИС. Использование таких платформ позволяет интегрировать принципы гибкой разработки (Agile) с необходимостью создания строго структурированной архитектуры (RUP).

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

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

2.1. Анализ бизнес-процессов ресторана и расчет масштабируемости

Ключевые бизнес-процессы ресторана, подлежащие автоматизации, включают:

1. Прием и обработка заказа (Официант → Система).
2. Управление производством (Система → Повар).
3. Учет запасов и работа с поставщиками (Менеджер).
4. Контроль и анализ деятельности (Директор).

Моделирование с использованием Диаграмм Потоков Данных (DFD)

DFD-диаграммы наглядно демонстрируют движение информации в системе.
Например, процесс Приготовление Блюд (Повар) может быть представлен так:

• Входной поток: «Заказ на кухню» (из системы официанта).
• Процесс: Проверка наличия ингредиентов, Приготовление, Изменение статуса заказа на «Готово».
• Выходной поток: «Статус готовности» (в систему официанта), «Списание ингредиентов» (в базу данных учета запасов).
• Хранилища данных: Справочник «Номенклатура блюд», «Запасы».

Расчет пиковой нагрузки и требований к масштабируемости

Требования к масштабируемости ИС ресторана определяются физической пропускной способностью заведения.

Согласно отраслевым нормативам, для комфортного размещения гостей требуется около 1,8 м² на одно посадочное место в зале ресторана. Если площадь зала ресторана составляет $S_{зал}$, то максимальное количество мест $N_{мест}$ равно:

Nмест = Sзал / 1.8 м²

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

X = 60 / t

где $t$ — среднее время приема пищи гостем в минутах.

Пример: Если среднее время обслуживания гостя составляет $t = 45$ минут, то коэффициент оборачиваемости $X = 60 / 45 \approx 1.33$ оборота в час. Почему этот коэффициент важен? Он позволяет точно прогнозировать потребность в вычислительных ресурсах для обеспечения бесперебойной работы в самые загруженные периоды.

Тогда пиковая нагрузка на систему (максимальное количество новых заказов в час) будет пропорциональна $N_{мест} \times X$, что требует от ИС обеспечения высокой производительности и многопользовательского режима без задержек.

2.2. Функциональные и интеграционные требования

Ключевые функциональные требования:

• Учет заказов: Оперативное создание, изменение и закрытие заказов с поддержкой сенсорных экранов для официантов.
• Производственный модуль: Доступ работников кухни к статусам заказа, таймеры приготовления.
• Логистика: Учет доставок, мониторинг загруженности службы доставки.
• Отчетность: Формирование отчетов по продажам, прибыльности, остаткам на складе (для Директора и Менеджера).

Интеграционные требования:

ИС должна быть интегрирована с бэк-офисными системами для ведения бухгалтерии и расчета заработной платы (например, с продуктами на базе «1С:Предприятие 8.x»).

Обмен данными с бэк-офисом реализуется через современные технические механизмы:

1. REST API (HTTP-сервисы): Обеспечивает двустороннюю синхронизацию номенклатуры, цен, и передачу финансовых документов (чеков, отчетов). Этот подход предпочтителен из-за своей гибкости и универсальности.
2. EDI (Electronic Data Interchange): Для взаимодействия с крупными поставщиками, EDI автоматизирует обмен стандартизированными электронными документами (заказы, накладные, счета-фактуры), исключая ручной ввод данных.

3. Архитектурное проектирование и обеспечение кибербезопасности

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

3.1. Разработка многоуровневой архитектуры (N-Tier)

Важно различать логическую (N-Layer) и физическую (N-Tier) архитектуру.

Логическая архитектура (N-Layer): Разделяет код внутри приложения:

1. Уровень представления (Presentation Layer): Отвечает за взаимодействие с пользователем (Web-сайт, мобильное приложение).
2. Уровень бизнес-логики (Business Logic Layer, BLL): Содержит основные алгоритмы и правила работы ресторана (расчет цен, управление заказами, инвентаризация).
3. Уровень доступа к данным (Data Access Layer, DAL): Обеспечивает взаимодействие с СУБД, скрывая детали хранения данных.

Физическая архитектура (N-Tier): Определяет физическое размещение логических слоев на различных серверах:

• Уровень клиента (Tier 1): Браузер пользователя.
• Уровень Web-сервера (Tier 2): Принимает HTTP-запросы (Web-серверы, Балансировщики).
• Уровень Сервера приложений (Tier 3): Содержит BLL и DAL, обрабатывает бизнес-логику.
• Уровень СУБД (Tier 4): Сервер базы данных.

Разделение на N-Tier позволяет независимо масштабировать уровень Web-серверов (для обработки трафика) и уровень серверов приложений (для обработки бизнес-логики), что критически важно для ИС HoReCa с ее скачкообразной нагрузкой.

Выбор серверной платформы:

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

• Apache Tomcat: Хорош для начального уровня и Web-сервисов, не требующих полного стека J2EE.
• JBoss (WildFly): Подходит для поддержки большинства возможностей J2EE и является стандартом для многих КИС.
• BEA WebLogic / IBM WebSphere: Коммерческие решения для enterprise-уровня с максимальными возможностями по управлению кластерами и безопасностью.

3.2. Стратегия защиты Web-приложения и данных

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

Применение WAF и защита от OWASP Top 10

Web Application Firewall (WAF) — это ключевой инструмент, который анализирует HTTP-трафик и блокирует атаки на уровне приложений (L7). Необходимость WAF в 2025 году особенно актуальна, так как зафиксирован рост кибератак на промышленные и корпоративные ресурсы.

WAF защищает от угроз, входящих в список OWASP Top 10:

Угроза OWASP	Описание и Защита WAF
SQL-инъекции (SQL Injection)	Атакующий вводит вредоносный SQL-код через поля ввода. WAF блокирует подозрительные синтаксические конструкции.
Межсайтовый скриптинг (XSS)	Внедрение клиентских скриптов в страницы. WAF фильтрует и обезвреживает исполняемый код в параметрах запроса.
Подделка межсайтовых запросов (CSRF)	Выполнение несанкционированных действий от имени пользователя. WAF проверяет наличие и валидность токенов защиты.
DDoS-атаки (L7)	Перегрузка приложения большим количеством легитимных или полулегитимных запросов. WAF применяет лимиты и поведенческий анализ.
RCE-атаки (Remote Code Execution)	Атаки удаленного выполнения кода, которые могут привести к полному компрометированию сервера. WAF блокирует характерные для RCE паттерны.

Для обеспечения безопасности Web-приложения необходимо применять WAF в сочетании с регулярным аудитом кода, использованием параметризованных запросов к БД (для исключения SQL-инъекций на уровне DAL) и строгим управлением жизненным циклом API.

4. Проектирование реляционной модели базы данных

Проектирование базы данных основано на реляционной модели Эдгарда Кодда. Цель — достижение логической целостности и минимизация избыточности через процесс нормализации.

4.1. Построение ER-диаграммы и ее трансформация

Проектирование начинается с концептуальной модели — ER-диаграммы (Сущность-Связь). Ключевые сущности для ресторана: Клиент, Заказ, Блюдо, Ингредиент, Поставщик, Сотрудник.

Трансформация связей M:M

Самым распространенным примером является связь между Заказом и Блюдом. Один заказ может включать много блюд, и одно блюдо может быть включено во множество заказов (связь M:M). В реляционной модели такая связь должна быть устранена.

1. Исходная связь: Заказ (M:M) Блюдо.
2. Трансформация: Создание промежуточной сущности ПозицияЗаказа.
3. Новые связи (1:M):
   • Заказ (1:M) ПозицияЗаказа (Связь «Один Заказ имеет Много Позиций»).
   • Блюдо (1:M) ПозицияЗаказа (Связь «Одно Блюдо включено во Много Позиций»).

Сущность ПозицияЗаказа будет содержать атрибуты, специфичные для конкретного заказа: Количество, ЦенаНаМоментЗаказа, СпецифическиеПометки. Ее первичный ключ будет составным, включающим ключи Заказа и Блюда.

4.2. Нормализация отношений: от 1НФ до НФБК

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

1. Первая нормальная форма (1НФ):

Требует, чтобы все атрибуты были атомарными (неделимыми), и не было повторяющихся групп атрибутов.
Нарушение: Если в таблице Заказ есть столбец Блюда со списком блюд через запятую, это нарушает 1НФ.
Устранение: Создание отдельных строк или отдельной таблицы (ПозицияЗаказа).

2. Вторая нормальная форма (2НФ):

Требует, чтобы отношение было в 1НФ, и все неключевые атрибуты полностью функционально зависели от всего первичного ключа. 2НФ актуальна только для таблиц с составными ключами.
Нарушение: В таблице ПозицияЗаказа (ID_Заказа, ID_Блюда, Название_Блюда) атрибут Название_Блюда зависит только от ID_Блюда (части ключа), а не от всего составного ключа.
Устранение: Атрибут Название_Блюда должен быть перенесен в таблицу Блюдо.

3. Третья нормальная форма (3НФ):

Требует, ��тобы отношение было в 2НФ, и отсутствовали транзитивные зависимости (неключевой атрибут не должен зависеть от другого неключевого атрибута).
Нарушение: В таблице Сотрудник (ID_Сотрудника, ФИО, ID_Должности, Оклад_Должности) атрибут Оклад_Должности зависит от неключевого атрибута ID_Должности.
Устранение: Создание отдельной таблицы Должность (ID_Должности, Оклад_Должности).

Углубленный анализ Нормальной формы Бойса-Кодда (НФБК)

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

Случай нарушения НФБК при соблюдении 3НФ:

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

• (A) ФИО
• (B) Телефон
• (C) Отдел
• (D) МенеджерОтдела

Функциональные зависимости (ФЗ):

1. (A, B) → (C, D) — Составной ключ: (ФИО, Телефон)
2. (C) → (D) — Отдел однозначно определяет Менеджера Отдела.
3. (D) → (C) — Менеджер Отдела однозначно определяет Отдел.

Если в таблице есть нетривиальная ФЗ, где детерминант не является суперключом, НФБК нарушается. Для данного проекта, где модель данных относительно проста (главным образом M:M-связи), достижение НФБК гарантирует максимальную логическую целостность и отсутствие избыточности. Не должна ли эта тщательная нормализация стать стандартом для всех критически важных корпоративных систем?

5. Принципы Web-дизайна и разработка пользовательского интерфейса

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

5.1. Применение эвристик юзабилити

Различие между UX и UI:

• UI (User Interface): Это «оболочка» — шрифты, кнопки, цветовая гамма, графика. Задача UI — сделать систему привлекательной и эстетически согласованной.
• UX (User Experience): Это «логика» — опыт пользователя, который включает навигацию, структуру, отклик системы и легкость достижения цели. Задача UX — сделать систему эффективной и интуитивно понятной.

Использование 10 эвристик Якоба Нильсена

При проектировании интерфейса Web-сайта и внутреннего рабочего места официанта необходимо руководствоваться эвристиками Якоба Нильсена для обеспечения высокого качества юзабилити:

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

5.2. Проектирование структуры навигации

Структура навигации (карта сайта) должна быть логично сгруппирована и адаптирована под целевую аудиторию:

1. Интерфейс Клиента (Web-сайт):

• Цель: Привлечение, информирование, конверсия (бронирование, заказ).
• Структура: Главная страница → Меню (с категориями) → Бронирование (календарь, выбор места) → Доставка/Самовывоз → Контакты.
• Требования: Интерфейс должен быть адаптивным (Mobile-First) и выполнен в единой цветовой гамме бренда.

2. Интерфейс Официанта/Менеджера (Внутреннее Web-приложение):

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

Заключение и отчет о реализации

В рамках проекта было выполнено комплексное проектирование информационной системы и Web-сайта для предприятия HoReCa, начиная с выбора методологии и заканчивая детальным проектированием БД и интерфейсов.

Ключевые результаты проектирования:

• Методологическая основа: Выбрана гибридная стратегия с элементами RUP (для архитектурной стабильности) и Agile (для итеративной реализации).
• Системный анализ: Произведен расчет масштабируемости, основанный на отраслевом коэффициенте оборачиваемости места $X = 60 / t$, что позволило определить требования к производительности N-Tier архитектуры.
• Архитектура: Обоснован выбор физически распределенной (N-Tier) архитектуры, обеспечивающей масштабируемость и безопасность. Внедрение WAF предложено как критический механизм защиты от атак OWASP.
• Модель данных: Разработана логическая модель, достигшая Нормальной Формы Бойса-Кодда (НФБК), что исключает избыточность и гарантирует логическую целостность данных, включая корректную трансформацию M:M связей в схеме.
• UX/UI: Проектирование интерфейса основано на эвристиках Якоба Нильсена, гарантирующих дружественность и эффективность системы как для конечного клиента, так и для внутреннего персонала.

Дальнейшая программная реализация должна включать создание схемы БД на выбранной СУБД (например, PostgreSQL), реализацию бизнес-логики на серверном языке (например, Java/Spring или Python/Django) и разработку адаптивного клиентского интерфейса (HTML5, CSS3, JavaScript/React). Только при строгом соблюдении этих проектных решений можно добиться долгосрочной стабильности и высокой производительности системы.

Фрагмент программной реализации (Схема БД, DDL-скрипт):

-- Таблица БЛЮДА (Достигнута НФБК)
CREATE TABLE Dish (
    Dish_ID SERIAL PRIMARY KEY,
    Name VARCHAR(100) NOT NULL UNIQUE,
    Price NUMERIC(10, 2) NOT NULL,
    Category VARCHAR(50)
);

-- Таблица ЗАКАЗЫ
CREATE TABLE Orders (
    Order_ID SERIAL PRIMARY KEY,
    Customer_ID INT REFERENCES Customer(Customer_ID),
    Order_Time TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
    Status VARCHAR(20) NOT NULL,
    Total_Amount NUMERIC(10, 2)
);

-- Таблица ПОЗИЦИЯ_ЗАКАЗА (Промежуточная сущность для связи M:M)
CREATE TABLE Order_Position (
    Order_ID INT REFERENCES Orders(Order_ID),
    Dish_ID INT REFERENCES Dish(Dish_ID),
    Quantity INT NOT NULL,
    Note TEXT,
    PRIMARY KEY (Order_ID, Dish_ID)
);

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

1. Благодатских В. А. и др. Стандартизация разработки программных средств: Учебное пособие. Москва: Финансы и статистика, 2005. 288 с.
2. Бойко В. В., Савинков В. М. Проектирование баз данных информационных систем. Москва: Финансы и статистика, 2004.
3. Вендров А. М. Проектирование программного обеспечения экономических информационных систем: Учебник. 2-е изд., перераб. и доп. Москва: Финансы и статистика, 2005. 544 с.
4. Вендров А. М. CASE-технологии. Современные методы и средства проектирования информационных систем. Москва: Финансы и статистика, 2006.
5. Диго С. М. Базы данных: проектирование и использование: Учебник. Москва: Финансы и статистика, 2005. 592 с.
6. Карпова Т. С. Базы данных: модели, разработка, реализация: учебное пособие для вузов. Санкт-Петербург: Питер, 2001. 304 с.
7. Конверс Т., Парк Дж., Морган К. РНР 5 и MySQL. Библия пользователя. Вильямс, 2006.
8. Кристиан Дари, Богдан Бринзаре, Филип Черчез-Тоза, Михай Бусика. AJAX и PHP. Разработка динамических веб-приложений: Учебник. Москва: Символ Плюс, 2006.
9. Лебедев С. В. Web – дизайн: Учебное пособие по созданию публикаций для Интернет. Издательский дом «Альянс – пресс», 2004.
10. Маклаков С. В. ВРWin и ERWin. САSЕ-средства разработки информационных систем. Москва: Диалог-МИФИ, 1999. 455 с.
11. Савицкая Г. В. Анализ хозяйственной деятельности предприятия: Учебник. Москва: Инфра-М, 2003. 400 с.
12. Зелковиц М., Шоу А., Гэннон Дж. Принципы разработки программного обеспечения / Пер. с англ. Москва: Мир, 1982. 386 с.
13. Информационные системы: Учебник для вузов. 2-е изд. Санкт-Петербург: Питер, 2005. 656 с.
14. Архитектура современных веб-сервисов и способы их защиты. URL: anti-malware.ru (дата обращения: 30.10.2025).
15. БАЗЫ ДАННЫХ: Теория нормализации. URL: osu.ru (дата обращения: 30.10.2025).
16. базы данных нормальные формы отношений. URL: nntu.ru (дата обращения: 30.10.2025).
17. ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА… Разработка системы информационной поддержки для предприятий общественного питания. URL: sowa-ru.com (дата обращения: 30.10.2025).
18. Информационные технологии в сфере общественного питания. URL: moluch.ru (дата обращения: 30.10.2025).
19. Многоуровневая архитектура. URL: core.ac.uk (дата обращения: 30.10.2025).
20. ОБЗОР МЕТОДОЛОГИЙ РАЗРАБОТКИ КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ. URL: science-engineering.ru (дата обращения: 30.10.2025).
21. Опыт проектирования информационной системы для ресторанов быстрого питания. URL: cyberleninka.ru (дата обращения: 30.10.2025).
22. Построение кибербезопасной архитектуры веб-приложений. URL: rezbez.ru (дата обращения: 30.10.2025).
23. Руководство Microsoft по проектированию архитектуры приложений. URL: microsoft.com (дата обращения: 30.10.2025).
24. СОВРЕМЕННЫЕ МЕТОДИКИ РАЗРАБОТКИ ИНФОРМАЦИОННЫХ СИСТЕМ. URL: urfu.ru (дата обращения: 30.10.2025).
25. Сравнение методов управления IT-проектами. URL: cyberleninka.ru (дата обращения: 30.10.2025).
26. Электронная энциклопедия. URL: ru.wikipedia.org (дата обращения: 30.10.2025).